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

ITV1 Failed Recordings

Peso said:
Update for anyone with a similar problem.
After two days of ensuring the 3 T2‘s saw BBC1 HD in the morning, all the days AR recordings, across various channels, were successful.
Thanks again to all contributors. Let’s hope the faulty mux is sorted soon.
Click to expand...
Spoke to soon. Mum just manually recorded the last 10mins of Everybody Loves Raymond on 4+1. And scheduled the next episode that followed immediately to record. T2 put in standby.
The following episode didn’t record. Still in the schedule with the sparkling AR symbol.
 
If you want recordings to work properly, don't leave the box sat receiving any service from PSB2, as well as before going to standby. All other muxes are fine.
The EPG service information on that mux. is so severely broken that it beggars belief.

I've been doing a lot of monitoring of it and it just doesn't complete transmission of the whole EPG schedule. Some of the data tables are corrupt and not compliant with the DVB spec.
Treating them as good doesn't work. Ignoring them doesn't work. Even filtering out the services with broken tables doesn't work.
This upsets both the Humax software and therefore the WebIf's EPG (which depends on the epg.dat file the Humax software writes - or rather doesn't write when on PSB2).

Having said that, the EPG Now/Next worked OK when I tried it on a couple of events but it's obviously impossible to test what other people's use cases are.

(This kind of follows on from some testing I did around this time last year, and a now out-of-date table in https://hummy.tv/forum/posts/176077)
 
prpr said:
I've been doing a lot of monitoring of it and it just doesn't complete transmission of the whole EPG schedule.
Click to expand...
I've just done a quick check here (Waltham - BBC-Emids/ITV1-Central East) and, although I can't test everything the way you can, I can see that the D3&4 (PSB2) mux is a bit flaky. I can get Now and Next on ITV1 and then an empty space that doesn't want to populate. I cannot tell whether the data is corrupt. Other ITV1 regions seem to fill up properly. Other channels on the multiplex are also lacking data. (Source: Hauppauge dongle on PC)
 
prpr said:
If you want recordings to work properly, don't leave the box sat receiving any service from PSB2, as well as before going to standby. All other muxes are fine.
The EPG service information on that mux. is so severely broken that it beggars belief.

I've been doing a lot of monitoring of it and it just doesn't complete transmission of the whole EPG schedule. Some of the data tables are corrupt and not compliant with the DVB spec.
Treating them as good doesn't work. Ignoring them doesn't work. Even filtering out the services with broken tables doesn't work.
Click to expand...
Have you reported this to whoever is responsible?
 
Is this not happening at Xtal Palace? Maybe I never leave a box on ITV (etc), or the Eagles sorted it out after trouncing Liverpool? Mitchell and Webb Aren't Helping recorded fine when it was running a few weeks ago (4seven was already on PSB2).

In relation to the up-thread discussion of SD vs HD, it's not for the nap of the snooker table or the blades of grass that sport is better in HD: you can see where the moving ball/racquet/sharp-studded boot is instead of a smear.
 
PSB2 aka D3&4 is now C&M in the cloud by BT for the companies concerned... https://www.mediaandbroadcast.bt.com/case-studies/coding-and-multiplex.html

Complaints to the Broadcasters (ITV, C4, C5) would be the correct route -- plus Everything TV (aka Freeview) and maybe Ofcom.

I would be gobsmacked if no-one is aware of the problem still - but then I am not affected by the issue with my personal viewing habits; nor do I have the Industry contacts I once had.
 
MartinLiddle said:
Have you reported this to whoever is responsible?
Click to expand...
No, because I don't know who runs Code'n'Mux for ITV et al on PSB2 (nor for the COM4-6 muxes). And the thought of trying to find out how is one of those things that you just know is going to be a fruitless exercise.
Peso said:
Can I ask how long on the HD mux before turning the T2 would be sufficient?
Click to expand...
Did you leave a word out - "turning off"? Sufficient for what?
I've just re-run my tests from last year and it turns out that PSB1 is the only one that is still operating as it was (PSB3 is worse than last year - details to follow). On PSB1, the entire EPG is received in exactly 5 minutes, as on the last test.
/df said:
Is this not happening at Xtal Palace?
Click to expand...
I would expect it is, but I don't have a transport stream from there, so unless you want to record me 10 minutes from anything on PSB2 and strip out all the PIDs apart from 18 and send me the zipped result, then I don't know. You'll probably need something to do the stripping - attached. Run it as tsfilt 18 <input.ts >output.ts
 

Attachments

Rodders53 said:
PSB2 aka D3&4 is now C&M in the cloud by BT for the companies concerned... https://www.mediaandbroadcast.bt.com/case-studies/coding-and-multiplex.html
Click to expand...
I looked at the Contact Us page linked from there and it's pointless. The rest of it is just 'corporate bollocks'.
Complaints to the Broadcasters (ITV, C4, C5) would be the correct route -- plus Everything TV (aka Freeview) and maybe Ofcom.
Click to expand...
That'd get filtered by the clueless morons on the front end.
I would be gobsmacked if no-one is aware of the problem still
Click to expand...
Well the problem from last year I suspect is the same as the one this year, but I don't know for sure, so probably they don't know.
but then I am not affected by the issue with my personal viewing habits; nor do I have the Industry contacts I once had.
Click to expand...
Likewise. I never watch stuff live from PSB2 and very rarely record it, but it would always be from a box sat on PSB3.
 
Times to populate EPG tables on various muxes (as received from Waltham).
Today's results (with problematic services filtered out) and changes from last year:

MuxNow/Next
Current mux		Now/Next
Other muxes		Schedule
Current mux		Schedule
Other muxes		Comments
PSB12s5s30s5mNo change; Ideal
PSB22s10s7m40 (was 30s)14m30 (was 13m45)Much worse on Schedule Current
PSB32s5s30s9m (was 5m)Surprisingly worse on Schedule Other
COM42s5s90s9m30 (was 8m)Minor worse
COM52s5s80s (was 50s)9m (was 13m)Puts it in line with the other COMs
COM62s5s90s9mNo change
Local2s5s (was 2m)90s (was 7m45)12m30 (was 52m)Much better; Probably as expected now
 
prpr said:
Which? The former or the latter?
How would a 15 year old box "manage to get it from the internet"? That's just a silly expectation. Even now there is no standard.
Click to expand...
I agree it is a silly expectation but i meant its a silly way to do it because of that limitation. Its more half baked than hybrid to me.
 
I still use Disable-DSO package (or do I mean Disable-OTA?) with its schedule event creation, so all my HDR Fox T2s power on to channel 250 for 20 mins from 4:20am to 4:40am. Given 250 is on PSB1 that should do the job.

I also have a timer wake set from 16:20 to 16:40 every day to BBC1 HD in case I spot something during the day at work that I want to record that evening by RS. That should also do the job.
 
prpr said:
No, because I don't know who runs Code'n'Mux for ITV et al on PSB2 (nor for the COM4-6 muxes). And the thought of trying to find out how is one of those things that you just know is going to be a fruitless exercise.
Click to expand...
My understanding is that the information has now been passed to someone at Humax with contacts at the broadcasters.
 
To add some examples to illustrate the table data corruption, service 4287 being "BBC TWO" on PSB1:
Code: 
11/01 16:13:37 Service  4287 Table 60 Version 09 was 09
11/01 16:13:39 Service  4287 Table 60 Version 09 was 09
11/01 16:13:51 Service  4287 Table 60 Version 29 was 09 *
11/01 16:13:51 Service  4287 Table 60 Version 09 was 29 *
11/01 16:13:57 Service  4287 Table 60 Version 09 was 09
11/01 16:14:01 Service  4287 Table 60 Version 04 was 09 *
11/01 16:14:04 Service  4287 Table 60 Version 09 was 04 *
11/01 16:14:07 Service  4287 Table 60 Version 09 was 09
11/01 16:14:11 Service  4287 Table 60 Version 08 was 09 *
11/01 16:14:18 Service  4287 Table 60 Version 09 was 08
and
11/01 16:13:17 Service  4287 Table 61 Version 30 was 30
11/01 16:13:18 Service  4287 Table 61 Version 30 was 30
11/01 16:13:26 Service  4287 Table 61 Version 18 was 30 *
11/01 16:13:27 Service  4287 Table 61 Version 30 was 18 *
11/01 16:13:32 Service  4287 Table 61 Version 30 was 30
11/01 16:13:40 Service  4287 Table 61 Version 30 was 30
11/01 16:13:50 Service  4287 Table 61 Version 30 was 30
11/01 16:13:50 Service  4287 Table 61 Version 30 was 30
11/01 16:13:55 Service  4287 Table 61 Version 14 was 30 *
11/01 16:13:55 Service  4287 Table 61 Version 12 was 14 *
11/01 16:13:57 Service  4287 Table 61 Version 30 was 12 *
11/01 16:14:00 Service  4287 Table 61 Version 30 was 30
11/01 16:14:11 Service  4287 Table 61 Version 30 was 30
The Version number is a 5 bit field and should increment whenever there is a change of data in that particular table. The only discontinuity should be going from 31 back to 00.
As you can clearly see, the above breaks the rule and seemingly transmits (presumably) old data randomly.
Lines tagged with a "*" are invalid.

Currently (it was slightly different yesterday), from a 5 minute sample, the list of broken services is:
4287, 4672, 4736, 5696, 8600, 8601, 13024, 13144, 16170, 16188, 16194, 16322, 27232, 28032, 33856, 34240
which covers all muxes except PSB3 and COM5 which are both OK.

All of this only happens when receiving PSB2, not when receiving any of the other muxes.
 
prpr said:
The Version number is a 5 bit field and should increment whenever there is a change of data in that particular table. The only discontinuity should be going from 31 back to 00.
Click to expand...
It's obvious how you could ignore these corrupt entries in the firmware, but presumably the HDR Fox T2 does not.
 
MartinLiddle said:
My understanding is that the information has now been passed to someone at Humax with contacts at the broadcasters.
Click to expand...
Thanks Martin. If the information above could be passed on as well, that would probably be useful. I'll attach the 5 minute log the above was generated from. If anyone wants contact details, let me know.
 

Attachments

Owen Smith said:
It's obvious how you could ignore these corrupt entries in the firmware,
Click to expand...
I tried it, as I said up-thread. It doesn't get you a complete set of table data.
but presumably the HDR Fox T2 does not.
Click to expand...
Why would it? It's not in the spec.

Note this is nothing to do with AR/Now'n'Next per se, as that is on tables 4E and 4F which appear to be OK to me.
 
You must log in or register to reply here.
Back
Top