• 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.

GB News and E4 Extra on Freeview

peterpi

peterpi

Member
I am receiving my signal from the Carmel Transmitter in Carmarthenshire.

There are two issues I'm experiencing with the the above.

GB News on COM6 ArqB CH48 600.0Mhz keeps rebooting every few minutes. I do not have the same problem with the few other services that I've tried on this Mux. I did a retune earlier but still get the same problem.

E4 Extra COM5 ArqA Ch36 594.0Mhz. I don't have the option to record some of the programs in the planner, although most of them I can.

TAI

Peter
 
i'm sure these are Freeview things rather than HDR-FOX problems, hence the existence of the Freeview forum section.

I have also experienced reboots when tuned to specific non-mainstream services. As for not being able to set a recording (for specific EPG entries), again that sounds like a broadcaster cock-up. If there is no CRID code attached to the EPG, the recorder has no means to set a recording and you would have to do it as a manual timer event.
 
Years ago I had problems on one of my Humaxes (either the 9150T or the 2000T) where something to do with "red button services" appeared to be the problem on one of the C4 channels. On the Aura I've had a channel (A GREAT channel) going blank because it smells the internet and tries, but fails, to stream. Other Humaxes might reboot under these conditions (?) Does GB News try to stream? I have never left GBN on long enough to find out.;)
You might be able to determine if either of these is the cause. Chase play should stop red button problems and disconnecting from the internet should stop streaming ones.
 
Black Hole said:
i'm sure these are Freeview things rather than HDR-FOX problems, hence the existence of the Freeview forum section.

I have also experienced reboots when tuned to specific non-mainstream services. As for not being able to set a recording (for specific EPG entries), again that sounds like a broadcaster cock-up. If there is no CRID code attached to the EPG, the recorder has no means to set a recording and you would have to do it as a manual timer event.
Click to expand...
With the HDR-FOX T2 it does allow programmes to be selected from the EPG for recording.
BBC stopped supplying CRIDs for any programmes on BBC World Sv. about 4 five years ago, and since then I have been setting recordings from the EPG.

peterpi said:
E4 Extra COM5 ArqA Ch36 594.0Mhz. I don't have the option to record some of the programs in the planner, although most of them I can.
Click to expand...
Examples?
peterpi said:
GB News on COM6 ArqB CH48 600.0Mhz keeps rebooting every few minutes.
Click to expand...
You are not alone. That happens with some HDR-FOX T2s but not with all. There is an existing discussion but it doesn't progress much:
https://hummy.tv/forum/threads/reboots-after-a-retune-on-a-particular-channel.11211/post-172623
 
Last edited:
Thanks for the suggestion. I have two in the house, but mine has an audio compatibility problem, to do with which HDMI I use on the TV. I'll check to see if this one also has an isseu.

Pete
 
Luke said:
With the HDR-FOX T2 it does allow programmes to be selected from the EPG for recording.
BBC stopped supplying CRIDs for any programmes on BBC World Sv. about 4 years ago and through out that time I have been setting recordings from the EPG.
Click to expand...
It seems you're right, but I wonder how. CRIDs is how it recognises a programme is being broadcast in order to record it, at least for AR. I'm not so clear about the mechanism for auto-padding, but without CRIDs I doubt it recognises a programme title so you're left with the start and end times being advertised at the time you set the recording.

An experimental recording I set is shown in the WebIF schedule browser as having AR properties... but how could that work? All I can think of is that the lack of CRIDs countermands AR and makes it work the same as manual.

Somebody here has the Freeview spec, IIRC. What does that have to say?
 
Last edited:
It uses the Event ID, which will track any changes made in the Schedule. It follows the Now/Next to know when to record, just like anything else.
Here is some data from the latter for the WS for today:
Code: 
01/30 00:00:01 Event  6016:13275 4E:22 started 00:00:00 00:06:00 "BBC News" "" ""
01/30 00:06:01 Event  6016:13278 4E:23 started 00:06:00 00:54:00 "The Forum" "" ""
01/30 01:00:01 Event  6016:13281 4E:24 started 01:00:00 00:06:00 "BBC News" "" ""
01/30 01:06:01 Event  6016:13284 4E:25 started 01:06:00 00:54:00 "Business Matters" "" ""
01/30 02:00:01 Event  6016:13286 4E:26 started 02:00:00 00:06:00 "BBC News" "" ""
01/30 02:06:01 Event  6016:13289 4E:27 started 02:06:00 00:24:00 "The Newsroom" "" ""
01/30 02:30:01 Event  6016:13292 4E:28 started 02:30:00 00:02:30 "BBC News Summary" "" ""
01/30 02:32:30 Event  6016:13294 4E:29 started 02:32:30 00:27:30 "The Documentary" "" ""
01/30 03:00:01 Event  6016:13298 4E:30 started 03:00:00 00:06:00 "BBC News" "" ""
13275 etc. is the field in question in the above. If you look in the rsv.db database on the HDR, you will see the usevtid field populated with this value.
 
OK, so what you're saying is CRIDs are only useful for tracking series, whether a programme has already been recorded, and finding an alternative if a recording failed. I hadn't expected another level of abstraction to be necessary.
 
I thought CRIDs might be optional but didn't say anything because I always use padding rather than AR. I thought it might make a difference - but, thinking about it, I can't see why it would make any difference to setting a recording.
 
Black Hole said:
OK, so what you're saying is CRIDs are only useful for tracking series, whether a programme has already been recorded, and finding an alternative if a recording failed. I hadn't expected another level of abstraction to be necessary.
Click to expand...
The "another level of abstraction" is the instance of a broadcast detail for the programme. Without that all the CRIDs are useless. The CRIDs are the abstraction, while the events are the broadcasts.
Events are very specific. E.g. if the time shifts by 15 minute the broadcaster, if they wish to keep the data up to date, will issue a new event to replace the delayed event rather than use AR to track the previous expected event.
 
Last edited:
Luke said:
if the time shifts by 15 minute the broadcaster, if they wish to keep the data up to date, will issue a new event to replace the delayed event rather than use AR to track the previous expected event.
Click to expand...
How does that work? If it's a different event, how does the recorder know?
 
It's not a different event. The start/duration etc. data just gets modified for the existing one(s). e.g.
Code: 
02/01 00:11:05 Event  7168:29053 50:31 changed duration from 03:55:00 to 03:45:00 "Winterwatch: Winter Magic"
02/01 00:11:07 Event  7168:29054 50:31 changed time from 10:00:00 to 09:50:00 "U20s Six Nations: Scotland v Italy"
02/01 00:11:07 Event  7168:29054 50:31 changed duration from 02:10:00 to 02:20:00 "U20s Six Nations: Scotland v Italy"
and this is what then happened:
Code: 
02/01 01:55:31 Event  7168:29028 4E:12 started 01:55:00 04:10:00 "Winterwatch: Winter Magic" "/m/18AHQ" "/m-1895N/xB"
02/01 06:05:01 Event  7168:29053 4E:14 started 06:05:00 03:45:00 "Winterwatch: Winter Magic" "/m/18AHQ" "/m-1895N/yB"
02/01 09:49:16 Event  7168:29054 4E:15 started 09:50:00 02:20:00 "U20s Six Nations: Scotland v Italy" "/m/18EDK" "/m-18EDL/1B"
 
Last edited:
Black Hole said:
So "new event" was misleading then. Good.
Click to expand...
prpr said:
It's not a different event. The start/duration etc. data just gets modified for the existing one(s). e.g.
Code: 
02/01 00:11:05 Event  7168:29053 50:31 changed duration from 03:55:00 to 03:45:00 "Winterwatch: Winter Magic"
02/01 00:11:07 Event  7168:29054 50:31 changed time from 10:00:00 to 09:50:00 "U20s Six Nations: Scotland v Italy"
02/01 00:11:07 Event  7168:29054 50:31 changed duration from 02:10:00 to 02:20:00 "U20s Six Nations: Scotland v Italy"
and this is what then happened:
Code: 
02/01 01:55:31 Event  7168:29028 4E:12 started 01:55:00 04:10:00 "Winterwatch: Winter Magic" "/m/18AHQ" "/m-1895N/xB"
02/01 06:05:01 Event  7168:29053 4E:14 started 06:05:00 03:45:00 "Winterwatch: Winter Magic" "/m/18AHQ" "/m-1895N/yB"
02/01 09:49:16 Event  7168:29054 4E:15 started 09:50:00 02:20:00 "U20s Six Nations: Scotland v Italy" "/m/18EDK" "/m-18EDL/1B"
Click to expand...

The d-book that the HDR-FOX T2 is at least closely based on states:
"if a programme is significantly rescheduled the event_id is likely to change".

It doesn’t define what "significant" means but being delayed beyond the normal AR time window would be significant to some. Or by "significant" does it means beyond the current schedule?

That d-book spec does also state, as part of an example, that if the channel changes, then the event_id will change and goes on to state that it can be better for the recorder to track the CRID rather than the event_id. This implies that, at least for some changes, a new event_id has to be allocated.
 
Luke said:
"if a programme is significantly rescheduled the event_id is likely to change".

It doesn’t define what "significant" means
Click to expand...
These sort of loose definitions really annoy me and don't help anybody, especially the people who have to write the software.
Shoddy specifications, incomplete and open to interpretation, are everywhere.
 
I cant remember the exact event but when there was special broadcast by the queen all of the subsequent programmes got new eventids and the humax failed to record them :(
 
You must log in or register to reply here.
Back
Top