[mythtv] Update on adding running status to DVB EIT processing

[roger]

The code for robust handling of DVB EIT tables. It is based on the ETSI  
EN 300 468 V1.15.1 and ETSI TS 101 211 V1.12.1.

I have not put yet put in any code to handle unsynchronized version 
numbers and section structure between actual and other EIT tables. This 
a "severe" derogation from the standards which is mentioned in at least 
one earlier version of the one national implementation of the standards. 
I will leave that on the back burner for the time being.

So this leads me on to implementing "accurate scheduling" based on the 
running status of an "event". I will paraphrase what is said about this 
in the publicly available DTG  "UK Digital TV Receiver  
Recommendations". My words - "The only accurate way to determine when an 
event actually starts and stops is to monitor its transition to and from 
the present event section of the EIT p/f table".

This is signalled in two ways:-

1. The presence of the relevant event id in the present section of the 
p/f table.

2. The running status of the event being set to running (running is not 
allowed as a value in the "following" section of the table.

The running status of events in the schedule table should basically be 
ignored for our purposes. According to ETSI  the only values that 
running status can take when encoded into transmitted EIT schedule 
sections (as distinct from p/f sections) is either undefined (0) or 
off-air(5).

The start time and duration of events are scheduled times and are not 
accurate for recording purposes. There is no requirement for 
broadcasters to update them if an event is brought forward, delayed, 
extended or truncated.

So what I am suggesting is that where we have accurate running status 
available we change the scheduler behaviour to just handle the booking 
of recorders. The recorders themselves should interact with the eit 
cache to find the current running  status and then monitor the relevant 
pids on their tuned transport stream for changes to indicate when to 
start and stop (and maybe pause!) actual recording.

Stuart, is this even remotely close to what you meant by lazy scheduling.

Anyone else, any ideas on how this might be implemented?

In particular when an event overruns how do we indicate this to the 
scheduler and what should it do?

Roger