• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[webif] Web Interface version 1.0.17 released

Status
Not open for further replies.
af123 said:
No idea. It's <descriptor tag> <descriptor length> <unknown length> [<unknown>] <language> <warning - to end>

Could it indicate whether the warning string is compressed?

Edit: nope...
Click to expand...
As far as I can tell, nobody knows apart from those with access to the D Book..

Frequency doesn't tell me much:

Code: 
humax# epg dumpraw | grep content.d137.text: | sort | uniq -c
  475  content.d137.text:  ()
  96  content.d137.text: 00  (.)
  142  content.d137.text: 01  (.)
 
Thanks af123. Was really just wanting to confirm that the byte following 'descriptor_length' was actually a 'size' byte. I'd assumed it was from observatons, but wondered if anyone knew the purpose of that field. It must be guidance related, but I've never seen values in any following data byte other than zero or one. Can't be that important I reckon.
Edit: These two bytes correspond with the .hmt file bytes at offsets 0x3E0 and 0x73B which precede the guide language descriptor. When there is no guide text these .hmt bytes contain 0xFF00.
 
Last edited:
They've fixed the EPG data for the Hollyoaks Omnibus now... still no guidance text, maybe it's tamer than I've heard?
 
A friend has just upgraded to 3.0, and noticed an oddity: he doesn't see crash.log listed as one of the files to view on the Diagnostics page.

I suggested that perhaps the file /mod/tmp/crash.log needed to exist, zero-size, before it appeared in the list, but no: he reports that he does indeed have that file (0 bytes) but it still doesn't appear on the Diag page, like it does for me, running 2.23.

Obviously not an issue right now (although it might be if there's a crash) - is this something odd about firmware 3.0, or is there something else going on?

It's a fresh install of CF 3.0, on a new box with replacement disk.

thanks...
 
cdmackay said:
I suggested that perhaps the file /mod/tmp/crash.log needed to exist, zero-size, before it appeared in the list
Click to expand...
It does.
he reports that he does indeed have that file (0 bytes) but it still doesn't appear on the Diag page, like it does for me, running 2.23.
Click to expand...
I don't believe it. Works fine for me on my various boxes.
is this something odd about firmware 3.0, or is there something else going on?
Click to expand...
Firmware version is irrelevant.
 
Apols if this is now the wrong thread, but I couldn't find one for 1.0.18...

Occasionally, I find that some channels go missing from the EPG grid, as given by xepg.jim

These absences seem to relate to when the channel in question isn't broadcasting anything for the entire width of the EPG grid, e.g. CBeebies at 1am. In this case, pressing Later, to move the grid on a bit, causes the channels to return.

Would it be possible to have an option to change this behaviour, please? i.e. to always show all channels in this grid, regardless of whether they are currently broadcasting?

I often use the grid view as an "index" to allow me to bring up particular channels' page-per-channel views, i.e. as provided by e.g. xservice.jim?service=4173

Since, in that case, I'm not just interested in what is on right now, I do want to see the "missing" channels.


Alternatively, perhaps, is there a different way for me to get a list of channels that, when clicked, would take me to their respective page-per-channel views?

thanks much indeed...
 
This sounds like a bug rather than a deliberate design feature - you do say "occasionally", and my grid-view is currently listing BBC THREE, BBC FOUR, and ITV4+1 (none of which are transmitting anything but a place holder)..
 
Black Hole said:
This sounds like a bug rather than a deliberate design feature - you do say "occasionally", and my grid-view is currently listing BBC THREE, BBC FOUR, and ITV4+1 (none of which are transmitting anything but a place holder)..
Click to expand...

That's an interesting thought - I'd assumed it was deliberate.

But you're right: if I go to xepg.jim now, I can see CBeebies, despite it not showing any real programmes.

For me, I see it around midnight -- early hours -- and it's almost always CBBC/CBeebies (and their HD relations) that are missing. This happens several nights a week although, as you note, not every night. Sometimes it also loses BBC Three/Four (and HD), but not often.

As above, pressing "Later" to move the grid on a few hours always restores the missing channels to the grid.

And by "missing" I mean solely from the default view of xepg.jim.

Odd.

thanks again...
 
Interesting - I can see the same behaviour at the moment, although the same EPG grid on the RS web site is fine.
I'll take a look into it - not sure how easy it will be to fix though!
 
Before going too mad it may be worth checking these things aren't missing from the actual Humax epg.

I often check future recordings in the small hours using the TV. On occasion I've noticed that some don't have the i function available because the epg isn't populated for the programme and at least a few times I've found the SD has the programme and HD didn't. It doesn't bother me particularly but it occurs to me that this may be the reason for the symptoms described above, in which case it's presumably not a CF bug.
 
I have found out why the grid isn't always rendering properly and sometimes missing out entire channels..
It happens when the details for the currently showing programme aren't in the EPG cache file on the disk. I don't know why but last night when I was testing the data appeared to be aggressively purged almost as soon as the programme started. It looks fine on my box at the moment though.
I'm not sure if this is something caused by the broadcasters or related to the Humax firmware version or something else, nor can I explain why it looks fine here tonight.
 
/mod/webif/cgi-bin/channel.jim uses "Film4+1" to identify COM6.
As this channel is no longer on that Mux., it now identifies it as "Local", which it isn't.
To my mind this was always an odd choice. Why not use something like "ITV4"?
I've just edited my copies of that file and normality has been restored to the Channel Information (Diags page).
 
prpr said:
/mod/webif/cgi-bin/channel.jim uses "Film4+1" to identify COM6.
As this channel is no longer on that Mux., it now identifies it as "Local", which it isn't.
To my mind this was always an odd choice. Why not use something like "ITV4"?
I've just edited my copies of that file and normality has been restored to the Channel Information (Diags page).
Click to expand...
This is still outstanding...
 
raydon said:
Thanks af123. Was really just wanting to confirm that the byte following 'descriptor_length' was actually a 'size' byte. I'd assumed it was from observations, but wondered if anyone knew the purpose of that field. It must be guidance related, but I've never seen values in any following data byte other than zero or one. Can't be that important I reckon.
Click to expand...

I was wrong - it isn't a size byte at all but it does indicate if there is any more information associated with the guidance entry. That extra information happens to be just one additional byte which is supposed to show whether the guidance is general (such as flashing images etc. in which case it should be zero) or for adult content (1). When there is no extra information, the existence of the guidance descriptor itself indicates adult content.

So if that first byte is 0 then it's guidance for adult content;
Otherwise there are two bytes and: 1 1 means adult content, 1 0 means general guidance.

Edit: These two bytes correspond with the .hmt file bytes at offsets 0x3E0 and 0x73B which precede the guide language descriptor. When there is no guide text these .hmt bytes contain 0xFF00.
Click to expand...

From your notes in the HMT format description, guidance is present if those bytes contain 0x00FF or 0x0101 which tallies with the above although the second byte now looks more like a set of bits. I wonder what happens for the 0x0100 case?
I've set a test recording for tomorrow lunchtime (Can't Pay? We'll Take It Away - C5+1, 13:15 - Warning: Contains scenes of hardship some viewers might find distressing, guidance flags 0x0100) to see what ends up in the HMT file.

I've also updated the command line epg utility to display this information properly and support a new filter flag which can be used to select just the entries with the extended information (For example, use epg -G1 -/1 dump to see events from tomorrow with extended guidance info).

It's good to know what it means - not yet sure if it's useful. I suppose the web interface could show two different guidance icons; perhaps a red one for adult content.
 
Here's the information while it's recording:

Code: 
00003e0: 0100 1069 3743 6f6e 7461 696e 7320 7363  ...i7Contains sc
00003f0: 656e 6573 206f 6620 6861 7264 7368 6970  enes of hardship
0000400: 2073 6f6d 6520 7669 6577 6572 7320 6d69  some viewers mi
0000410: 6768 7420 6669 6e64 2064 6973 7472 6573  ght find distres
0000420: 7369 6e67 0000 0000 0000 0000 0000 0000  sing............
 
Status
Not open for further replies.
Back
Top