ITV1 Failed Recordings

[prpr]

Report today on AVForums that it has been fixed

Link?

Can you tell if it is now fixed?

Depends what you mean by "it".
I just tried a short (2 mins. or so) capture again (Waltham PSB2) and got these anomalies:

11/07 23:40:54 Service 16322 Table 61 Version 14 was 21 *
11/07 23:41:00 Service 16322 Table 61 Version 25 was 14 *
11/07 23:41:01 Service 16322 Table 60 Version 25 was 03 *
11/07 23:41:03 Service 16322 Table 61 Version 19 was 25 *
11/07 23:41:10 Service 16322 Table 60 Version 03 was 25 *
11/07 23:41:12 Service 16322 Table 61 Version 14 was 19 *
11/07 23:41:13 Service 33856 Table 60 Version 08 was 11 *
11/07 23:41:17 Service 16170 Table 61 Version 29 was 20 *
11/07 23:41:18 Service 33856 Table 60 Version 11 was 08 *
11/07 23:41:18 Service 28032 Table 60 Version 10 was 18 *
11/07 23:41:18 Service 33856 Table 60 Version 09 was 11 *
11/07 23:41:21 Service 16170 Table 61 Version 20 was 29 *
11/07 23:41:21 Service 33856 Table 60 Version 09 was 10 *
11/07 23:41:22 Service 33856 Table 61 Version 17 was 07 *
11/07 23:41:23 Service 33856 Table 60 Version 17 was 10 *
11/07 23:41:25 Service 28032 Table 60 Version 18 was 10 *
11/07 23:41:31 Service 28032 Table 61 Version 06 was 18 *
11/07 23:41:32 Service 33856 Table 61 Version 08 was 17 *
11/07 23:41:32 Service 33856 Table 60 Version 12 was 17 *
11/07 23:41:33 Service 28032 Table 61 Version 18 was 06 *
11/07 23:41:35 Service 28032 Table 60 Version 10 was 18 *
11/07 23:41:35 Service 33856 Table 61 Version 05 was 08 *
11/07 23:41:38 Service 33856 Table 60 Version 11 was 12 *
11/07 23:41:39 Service 28032 Table 60 Version 18 was 10 *
11/07 23:41:41 Service  4287 Table 61 Version 04 was 14 *
11/07 23:41:42 Service  4287 Table 60 Version 11 was 05 *
11/07 23:41:45 Service 13024 Table 60 Version 03 was 12 *
11/07 23:41:46 Service  8601 Table 50 Version 05 was 17 *
11/07 23:41:47 Service  8600 Table 50 Version 05 was 17 *
11/07 23:41:48 Service 28032 Table 61 Version 06 was 18 *
11/07 23:41:48 Service 13024 Table 60 Version 12 was 03 *
11/07 23:41:48 Service  8601 Table 50 Version 17 was 05 *
11/07 23:41:49 Service  4287 Table 61 Version 14 was 04 *
11/07 23:41:49 Service  4287 Table 60 Version 05 was 11 *
11/07 23:41:49 Service 28032 Table 61 Version 18 was 06 *
11/07 23:41:56 Service  7168 Table 60 Version 25 was 26 *
11/07 23:42:00 Service 28032 Table 60 Version 10 was 18 *
11/07 23:42:00 Service 16322 Table 61 Version 25 was 14 *
11/07 23:42:01 Service 16322 Table 60 Version 25 was 03 *
11/07 23:42:04 Service 16322 Table 60 Version 03 was 25 *
11/07 23:42:05 Service  5696 Table 60 Version 15 was 19 *
11/07 23:42:08 Service  5696 Table 60 Version 19 was 15 *
11/07 23:42:08 Service 28032 Table 60 Version 18 was 10 *
11/07 23:42:08 Service  8600 Table 50 Version 17 was 05 *
11/07 23:42:09 Service 33856 Table 60 Version 08 was 11 *
11/07 23:42:12 Service 16322 Table 61 Version 14 was 25 *
11/07 23:42:14 Service 16170 Table 61 Version 29 was 20 *
11/07 23:42:17 Service 33856 Table 60 Version 11 was 08 *
11/07 23:42:17 Service  8601 Table 50 Version 05 was 17 *
11/07 23:42:18 Service 16170 Table 61 Version 27 was 29 *
11/07 23:42:18 Service  5696 Table 60 Version 15 was 19 *
11/07 23:42:18 Service  7168 Table 60 Version 25 was 26 *
11/07 23:42:18 Service  5696 Table 60 Version 19 was 15 *
11/07 23:42:19 Service 16170 Table 61 Version 25 was 27 *
11/07 23:42:20 Service  8601 Table 50 Version 17 was 05 *
11/07 23:42:21 Service 16170 Table 61 Version 20 was 25 *
11/07 23:42:21 Service 33856 Table 61 Version 17 was 07 *
11/07 23:42:23 Service 33856 Table 60 Version 17 was 11 *
11/07 23:42:26 Service 33856 Table 61 Version 07 was 17 *
11/07 23:42:32 Service 33856 Table 60 Version 12 was 17 *
11/07 23:42:33 Service 33856 Table 60 Version 10 was 12 *
11/07 23:42:41 Service  4287 Table 61 Version 04 was 14 *
11/07 23:42:42 Service 33856 Table 61 Version 07 was 08 *
11/07 23:42:45 Service 13024 Table 60 Version 03 was 12 *
11/07 23:42:46 Service  4287 Table 60 Version 11 was 05 *
11/07 23:42:46 Service  4287 Table 61 Version 14 was 04 *
11/07 23:42:48 Service 13024 Table 60 Version 12 was 03 *
11/07 23:42:49 Service  4287 Table 60 Version 05 was 11 *
11/07 23:42:53 Service 33856 Table 60 Version 10 was 11 *
11/07 23:42:57 Service 33856 Table 61 Version 05 was 07 *
11/07 23:42:58 Service 33856 Table 60 Version 09 was 11 *
11/07 23:43:00 Service 16322 Table 61 Version 25 was 14 *
11/07 23:43:01 Service 16322 Table 60 Version 25 was 03 *
11/07 23:43:02 Service 16322 Table 60 Version 03 was 25 *
11/07 23:43:07 Service 16322 Table 61 Version 14 was 25 *
11/07 23:43:15 Service 16170 Table 61 Version 29 was 20 *

which covers these services: 4287,5696, 7168, 8600, 8601, 13024, 16170, 16322, 28032, 33856

So there is still something wrong with the Schedule tables and I don't know what they have fixed.
I could never reproduce any problems with Now/Next nor find fault with the tables, except for lagginess compared to PSB1/3 (and it's still roughly 15s adrift as previously).

 

[MartinLiddle]

Depends what you mean by "it".
which covers these services: 4287,5696, 7168, 8600, 8601, 13024, 16170, 16322, 28032, 33856

So there is still something wrong with the Schedule tables and I don't know what they have fixed.
I could never reproduce any problems with Now/Next nor find fault with the tables, except for lagginess compared to PSB1/3 (and it's still roughly 15s adrift as previously).

I am now able to make recordings which play without problem from the D3 & D4 multiplex. I have to say that I don't understand what these tables are used for. Do you want me to pass your observations on to Humax?

 

[Black Hole]

Do you want me to pass your observations on to Humax?

What can Humax do about it, or is that a conduit to the broadcasters?

 

[prpr]

I have to say that I don't understand what these tables are used for.

They contain the EPG schedule information. It may help to read the spec. in EN 300 468.
Section 5.2.4 on pages 32/33 contains most of the information pertinent to this problem.

I picked the first service on the above list, namely 4287 which is "BBC TWO", and did some more analysis. Here is a filtered, de-duplicated and re-ordered (as it's not transmitted sequentially) dump of the table 60 contents:

Service  4287 60:06 Sec   0 SegLast   0
Service  4287 60:06 Sec   8 SegLast   8
Service  4287 60:06 Sec  16 SegLast  17
Service  4287 60:06 Sec  17 SegLast  17
Service  4287 60:06 Sec  24 SegLast  24
Service  4287 60:06 Sec  32 SegLast  32
Service  4287 60:06 Sec  40 SegLast  40
Service  4287 60:06 Sec  48 SegLast  48
Service  4287 60:06 Sec  56 SegLast  56
Service  4287 60:06 Sec  64 SegLast  64
Service  4287 60:06 Sec  72 SegLast  72
Service  4287 60:06 Sec  80 SegLast  80
Service  4287 60:06 Sec  88 SegLast  88
Service  4287 60:06 Sec  96 SegLast  96
Service  4287 60:06 Sec 104 SegLast 104
Service  4287 60:06 Sec 112 SegLast 112
Service  4287 60:06 Sec 120 SegLast 120
Service  4287 60:06 Sec 128 SegLast 128
Service  4287 60:06 Sec 136 SegLast 136
Service  4287 60:06 Sec 144 SegLast 144
Service  4287 60:06 Sec 152 SegLast 152
Service  4287 60:06 Sec 160 SegLast 160
Service  4287 60:06 Sec 168 SegLast 168
Service  4287 60:06 Sec 176 SegLast 176
Service  4287 60:06 Sec 184 SegLast 184
Service  4287 60:06 Sec 192 SegLast 192
Service  4287 60:06 Sec 200 SegLast 200
Service  4287 60:06 Sec 208 SegLast 208
Service  4287 60:06 Sec 224 SegLast 224
Service  4287 60:06 Sec 232 SegLast 232
Service  4287 60:06 Sec 240 SegLast 240
Service  4287 60:06 Sec 248 SegLast 248

Service  4287 60:05 Sec  81 SegLast  81 *
Service  4287 60:31 Sec 145 SegLast 145 *
Service  4287 60:24 Sec 209 SegLast 209 *

The table is split into sections, in blocks of 8 segments. Most of the sections only have one segment e.g. 0, 8, 24, 32 etc. all the way to 248 (which is the max. as it's an 8 bit field). But you will note that section 16 has two segments: 16 and 17.
You will further note that the three erroneous version sections at the end (labelled with *) contain information which doesn't correctly belong to any block of 8. This is clearly obsolete data which should have been removed but hasn't been.
A further decode on segments 81, 145 and 209 reveals that they are all identical, and then on a hunch I had a look at segment 17 which was the same and contains:

Event ID 29580 Date 2025/11/08 08:10:00 Dur 00:25:00 Run 0 Clear
Event name "Blue Peter: Canadian Adventure..."
Event CRID 0x11 "/m/1FM6T"
Event CRID 0x12 "/m-1DTBU/02"

Event ID 29581 Date 2025/11/08 08:35:00 Dur 00:10:00 Run 0 Clear
Event name "Newsround"
Event CRID 0x11 "/m/1FPPN"
Event CRID 0x12 "/b-3N5GG/02"

Event ID 29582 Date 2025/11/08 08:45:00 Dur 00:30:00 Run 0 Clear
Event name "Deadly Predators"
Event CRID 0x11 "/m/NUZ6"
Event CRID 0x12 "/m-NUYI/02"

Segment 17 is correct as far as the rest of the EPG data for this service goes. The other three segments should not be there.

Now, section blocks 0-248 covers a range of 256 possible segments (8 bit field) and table 60 contains the schedules for days 0-3 (FYI, 61 contains days 4-7).
So, that's 64 segments per day. And what is the offset between 17, 81, 145 and 209? Yep, 64.
So I surmise that the data that's currently in 17 was in 81 yesterday, 145 the day before and 209 the day before that. On the four days before that it would have been shuffling through table 61.

My suspicion is that there's a software bug in whatever is generating the Service Information on PSB2 that doesn't clear data in all 8 segments of a section when the base segment of a section changes.

This could happen at any time, but is made obvious when data is shuffled between segments at the change of day.
This also explains why the problem is never the same two days running.

I expect all the other services with erroneous data have something very similar, but I'm not going to analyse them all as I think I've nailed it already.

Do you want me to pass your observations on to Humax?

Feel free. I would like the mux. operator to fix the data problems which are obviously still present. And then they can send me the cheque for doing their job for them...

Attached is the raw log file from the above.

 

[prpr]

What can Humax do about it, or is that a conduit to the broadcasters?

He said so earlier, post #75.