[mythtv] Questions for the DVB guys

[Chris Birkinshaw]

>>>>
>>>> I have a few questions for the DVB developers:
>>>>
>>>> 1. Have you considered triggerring of recording start/stop times by
>>>> the
>>>> updating of EITpf tables? The BBC are using reactive (i.e. triggered
>>>> from
>>>> the playout automation server) EITpf triggering on Mux1 and MuxB 
>>>> which
>>>> means that EITpf always rolls over on the last trail before the next
>>>> program no matter how late or early it is. This is the way the whole
>>>> network will be going in the not too distant future, and there is
>>>> mounting
>>>> pressure on PVR manufacturers to support this mode of operation.
>>>>
>>> Chris,
>>>      Could you expand on this a bit more ? Do you mean a particular
>>> table or a value within a table ?
>>
>>


In the UK DTT system there are 3 types of EIT tables on PID 18:

Table 79: EITpf (now and next)
Table 96: EITs (first 4 days)
Table 97: EITs (following 4 days, slower repetition rate)

There are also 2 sources for EITpf - the EITactual carried in the same 
transport stream as the service in question, or the EITother carried in 
the other 5 UK DTT transport streams (so called "cross-carry" data). 
The cross-carry data is generated from pre-collated schedules gathered 
from all multiplex operators and submitted to the transmitter sites, so 
if a program is running a few minutes late the EITother can often be 
incorrect. However, the EITactual on DTT muxes 1 and B is updated in 
real time and comes from the multiplex operator themselves.

It would therefore be possible to have a check box for each multiplex 
in the mythtv config which enabled the following behaviour (it is very 
feasible that in future this feature will not be limited to muxes 1 and 
B):

1. Event is scheduled by user. I am assuming that the mythtv EIT parser 
is indiscriminate and so populates the database with all EIT tables, 
i.e. actual/other, EITpf/EITs etc...
2. Event is about to start, recording machinery is on standby
3. We then wait until the EITactual table 79 for this service (i.e. the 
EITpf Present event grabbed from the same TS as the program to be 
recorded) undergoes a Version Number change.
4. Following the version number change the service ID of the current 
event is checked against that in the database, and if correct the 
recording is started.

Does this make more sense?


Regards,

Chris.