Fixing unviewable TV (but actually streamed) shows in the EPG

D

/df

Well-Known Member
Nowadays quite a few channels, generally the higher-numbered LCNs, in the TV section of the EPG are actually transmitting OTA for some short period and otherwise delivering streamed content. ISTR that a channel can count as TV (LCN < 200) if its OTA content is at least 2 hours per day. The Freeview authority assumes that connected devices can show these streamed shows transparently, but since the HD[R] Fox T2 s/w pre-dates the relevant standards this assumption doesn't apply here. The on-screen EPG (so also the Webif EPG), shows the streamed and OTA shows together with no apparent distinction.

If watching live, the viewer may see the same show scheduled for both 03:30 and 19:30 and decide to watch the latter instance, when in fact the wee hours version is OTA and the early evening one is streamed, leading to a data display and even more disappointment than is usual for the high-numbered LCNs. Eg, as I type, TogetherTV claims to be showing Edwardian Farm, but what it's actually showing is a data panel that says its OTA hours are 05:00-08:00 and to "Please wait up to a minute while channels load" (which on our platform never happens, as if the box was disconnected from the internet). Similarly, a scheduled recording or reminder could produce unviewable content with no warning, or the missed/conflict resolution algorithm could replace a potentially viewable show with a dud (if the CRIDs match).

What can be done? Surely it's not practical (or worthwhile) to implement the missing streaming support transparently in the CF, and if it might be possible in a Portal app it wouldn't be transparent. What about fixing the EPG instead?

1. Is there a way to distinguish when a channel is actually OTA? Obvs it could be set up with static data (eg, from above, {{83 {{"05:00" "08:00"}} ...}) at the cost of ongoing tunefix-style maintenance.

2. (long shot) Can the raw EPG data be hacked in such a way that non-OTA shows are distinguishable both in the on-screen and Webif EPG displays? Eg, prefixing the display title with [Streaming only] and replacing the CRID with some fake value.

3. (more likely) Can the extracted EPG data used in the Webif be hacked similarly, so that the Webif EPG and conflict checker (and schedchk) would be able to distinguish between "real" and streamed shows?
 
I can see this might be possible in the WebIF/RS views, but how do you expect to massage the EPG data in such a way that it "fixes up" the on-screen EPG? Yes, maybe the database can be hacked (although I guess it is locked except just after boot), but what would stop a refresh overriding the hack?
 
/df said:
Is there a way to distinguish when a channel is actually OTA?
Click to expand...
Not that I can see. The EPG data just churns throughout the day as if it were on air all day, on the services that choose to populate the EPG for 24 hours/day, as opposed to those that don't. Getting accurate information of what's actually available when is a bit of a bugger. Who's going to sit up in the middle of the night to verify it? Best thing to do would be just to delete or ignore all these P/T services and leave 'em to it.
 
How is a Smart TV that meets the new standards supposed to know whether any particular programme is being transmitted OTA or streamed?
Presumably there must be something in the EPG somewhere that tells it or does it access the web to locate the information?
Either way if the standards documents are publicly available we should be able to work out if a programme is OTA or Streamed unless the protocols are only available to fee paying manufacturers.

But I suppose there may not be any advance notification and it is only when the the TV finds the channel isn't being broadcast that it switches to streaming mode.

How does the Aura handle such channels? and what about tuner boxes like the HDhomeRun? Since I have one I'll try a few experiments
 
Last edited:
prpr said:
Best thing to do would be just to delete or ignore all these P/T services and leave 'em to it.
Click to expand...
Certainly my preferred solution on my Humaxes (no CF) which are not permanently connected to the internet.
 
MymsMan said:
How is a Smart TV that meets the new standards supposed to know whether any particular programme is being transmitted OTA or streamed?
Presumably there must be something in the EPG somewhere that tells it
Click to expand...
I think the relevant info is in the transport stream for the respective service. If you recall, early firmwares used to crash when a streamed service was selected. Perhaps Humax had included industry reference code for extracting a URL from the TS and setting up the stream while not having provided the means to use that stream.
 
prpr said:
Best thing to do would be just to delete or ignore all these P/T services and leave 'em to it.
Click to expand...
It would be nice to have an option in Tunefix to remove channels by Named groups, e.g.
  • Internet only channels
  • Part time channels
  • Adult channels
  • Radio channels
  • Childrens channels
  • etc
I sometimes look at the removed channel number ranges in Tunefix settings and struggle to remember why they are there
I would prefer not to have to update the tunefix settings every time a new part time channel comes
 
As to how the receiver knows what sort of content is being shown, D-Book 7 Pt A (2011) specified that a data_broadcast_id should be present in the Program Specific Information for the show, whereas that field should be in the channel's entry in the Service Description Table for a data-only (200+) service. The data_broadcast_id was supposed to point to MHEG-5 (teletext on steroids) application UKengine1.

The HD[R]-Fox T2 firmware knows enough about MHEG-5 to be able to switch to another broadcast channel (eg, BBC Red Button), but crashed, as I recall, when told to load what D-Book 7 Pt B calls "linear IP streaming content".

Nowadays, hbbTV seems to be the thing. Then your TV is a computer running HTML5 applications, like Freeview Play, in a custom web browser with a DVB-T[2] plugin (why you should never buy a Smart TV). According to the WP article, the first version of hbbTV relevant to the UK was 2016 which included support for the UK MHEG-5 application.

Since the CF extracts the EPG data from the Humax firmware, it should be possible to tweak the data in that process or subsequently.

Changing the data used in the on-screen EPG, a long shot as I said, would require hooking into the humaxtv program, But that has already been done. Perhaps investigating where the name epgsavedata is used would lead to some loop that serializes the EPG data before writing it, where the original data might be patched.
 
MymsMan said:
...
I would prefer not to have to update the tunefix settings every time a new part time channel comes
Click to expand...
This information is not obviously available from the Freeview site ("You had one job").

Currently, filtering the General Entertainment table at https://en.wikipedia.org/wiki/List_of_DTT_channels_in_the_United_Kingdom for 'stream' in the Notes column gives a reasonably useful list with the time range in the Broadcast Hours column. It's wrong on That's TV(UK) and its relations, but I'm not sure what the right answer is: probably the Xmas rebranding hasn't been added.

Hence why it would be convenient to extract the information in real time.
 
/df said:
a data_broadcast_id should be present in the Program Specific Information for the show, whereas that field should be in the channel's entry in the Service Description Table for a data-only (200+) service.
Click to expand...
According to EN 300468, the data_broadcast_id descriptor is only in the PMT and is a shortened form of the data_broadcast descriptor which is in the SDT and EIT.
When I wrote my decoder, I never saw any such descriptor entries in the EIT or SDT. I haven't done the PMT decode bit, but I doubt anything's there either.
I've seen three private tag values, but not looked further into them due to lack of information.
Changing the data used in the on-screen EPG, a long shot as I said, would require hooking into the humaxtv program, But that has already been done. Perhaps investigating where the name epgsavedata is used would lead to some loop that serializes the EPG data before writing it, where the original data might be patched.
Click to expand...
The file you mention is HD specific, and different on HDR. But it's only persistent storage, and presumably only read at startup to populate the EPG quickly whilst waiting for the OTA data to update it - it doesn't change what's in the memory of the humaxtv process or what gets displayed on screen.
 
If the saved EPG data (however named) has some flag in the relevant programmes there is a way forward for the CF/Webif side, but not obviously for the on-screen EPG.

But whatever call chain in the Humax blob writes that saved data must be starting from the (or an) internal copy of the EPG data pulled from DVB. My vague hope was that given a call in that chain, like result_type res = mung_epg_data(epg_data *data, other_args), it would be possible to patch fields accessible from the data pointer. But it's quite possible that the application stashes multiple copies of the EPG data. It might also continually update the data as it's received from DVB, so that a once-patched data item might be overwritten or recycled, unless the call where that update occurs can be located and hooked.
 
Last edited:
Not sure if this will help but I noticed recently that a fair number of these BB streamed programs may have relatively small description on EPG and also often lack CRID info (or sometimes they use what looks like a common or placeholder CRID).
 
However, Together TV has full EPG descriptions and distinct CRIDs even when the show is not on DVB-T. Maybe they use the same EPG data for satellite and broadcast 24hrs there.
 
You must log in or register to reply here.
Back
Top