EITpf timing for recordings

[David Matthews <dm@…>]

This patch monitors EIT present/following and sets a bookmark at the start when the programme begins and extends the recording time until it ends. I started this almost two years ago when I almost lost a recording I particularly wanted because a previous programme overran and initially I just wanted to see if it would work. In the UK programmes generally run a minute or two later than clock time but occasionally they can be significantly later. It seems, though, that the BBC and some of the other broadcasters link EITpf to the programme roll-out so it is accurate to the second. Certainly the bookmarks put in by this patch appear exactly on the ident on BBC and, I think ITV and Channel 4. In the UK EITpf is used in Freeview+ and Freesat+ PVRs and it seems it is also mandated by the standards I've found for New Zealand and the Nordig group.

I found a problem with this when recording more than one programme on the same multiplex and traced it to the way EIT pids are handled. The fix for it is sufficiently distinct from this that I will create a separate ticket for it.

This patch is currently for Freeview only in the UK. I do have a patch for Freesat but I'd like to test it a bit more.

Currently this patch enables both bookmarking and extending unconditionally. It almost certainly needs a switch of some sort to enable or disable it. That might be global, per listings source or per recording.

Finally, there is the issue of the interaction of this with the scheduler. Currently, the scheduler decides when to start and when to finish a recording but with EITpf timing the scheduler only decides when to start and the tuner is in use as long as the programme runs. That hasn't been a problem for me because I have enough tuners and I also set a global start-early and end-late of a minute to avoid conflicts.

David

[paulh]

Bumping to 0.29

[Stuart Auchterlonie]

Milestone renamed

[Stuart Auchterlonie]

Moving remaining open tickets to 0.28.2 milestone

[Stuart Auchterlonie]

Moving remaining open tickets to 29.2 milestone

[Klaas de Waal]

Manually applied the patch to the current master and generated the patch again to enable testing with the current master.

[Klaas de Waal]

I have tested the patch with the local DVB-C signal (Ziggo / The Netherlands) using a single tuner and a single recording per tuner.

Timing accuracy
The EITpf is, as I understand it, used to update the EPG and this means that the EITpf timing used in this patch is not more accurate than the EPG itself.

Bookmark
The bookmark that is set to mark the start of the program is correct. However, MythTV has already the capability to set a bookmark at the start of the program when the recording is scheduled to start earlier. In my system it feels that both ways of generating start-of-program bookmarks have the same accuracy.

End of recording
Extending the recording until the EITpf signals the end works correct; as my EPG is quite good the only way to test this is to schedule the recording to stop before the end of the program. The patch does cause the recording to continue until the end of the program.
However, as mentioned in the original description, this means that you cannot schedule a recording anymore to end before the end of the program.
AFAIK the EPG is updated from the EIT as long as the end time of the program is in the future, so recordings should already be extended automatically.

Incorrect recording
On my system the recording of the news bulletin went wrong.
The news bulletin is repeated a number of times at night and the recording of one instance of this was extended until the end of the last repeat. Investigation shows that all repeats do have the same "program ID" (something like "bds.tv/123456") and this causes the code to see all repeats as a single program.

What about RST
A DVB transport stream can have an RST (running status table) (PID 0x13) which should give really accurate start- and endtimes, better than the EIT. This is the table that should be used! However, my DVB-C signal does not have the RST tables.

Summary
The EIT data goes into the EPG, the recordings are controlled by the EPG and if the EIT information is not in time propagated into the EPG then that is the problem that should be fixed, rather than setting up a parallel path that uses the same EIT data.

[Stuart Auchterlonie]

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] - ​https://github.com/MythTV/mythtv/issues