[mythtv] Adding RunningStatus information to DVB EIT processing

[Roger James]

Hi David,

Just to clarify. Are you referring to section 14.3.7 of Nordig Unified 
Requirements version 2.5.1?

Roger


On 2 September 2016 8:03:42 am David Matthews <dm at prolingua.co.uk> wrote:

>>>> Hi Stuart,
>>>>
>>>> I was thinking of just adding some in memory structures to monitor the
>>>> table versions and their segment structure. The aim would be to
>>>> implement the recommendations in section 4.1.9 of ETR 211. I do not plan
>>>> to interfere with the structure of the cache, just to better handle
>>>> removing defunct eits from it. So it is about EIT structure rather the
>>>> the event data itself.
>>>>
>>>
>>> I'd like to see a distinction in the reschedules requested from EIT.
>>>
>>> The long term data should trigger a lazy reschedule (ie. not now, but
>>> when it's convenient), whilst the short term data (now / next, RST)
>>> should trigger an immediate rescheduled if it changes
>>>
>>> That way we can reduce the scheduler runs, and coalesce them.
>>> By coalesce, I mean if you have multiple cards collecting EIT
>>> data, there is no need (with long term data changes) for the
>>> completion of collection on a mux on one card to trigger a
>>> reschedule.
>>>
>>> I think the EIT Scanner portion needs to be a bit more intelligent
>>> here.
>>>
>>> Thoughts?
>>>
>>>
>>> Regards
>>> Stuart
>>>
>>> ______________________________________________
>> Hi Stuart,
>>
>> That's pretty much exactly what I was thinking. But I was holding off
>> until I had chance to understand the scheduler a bit better. Do you have
>> any pointers for me in that area?
>>
>> I want to do an initial test that just relies on pf running status
>> changes to trigger scheduling, and see if it is enough to prioritise
>> those transitions in the scheduling run, and then go on to handle any
>> other either (non pf) transitions in the same run.
>>
>> Currently doing this in the Garrick theatre in London waiting for a show
>> to start :-)
>>
>> Roger
>
> Hi Roger and Stuart,
>
> When I looked at this the problem was that the Myth scheduler is based
> round the idea of having listings information that allows it to predict
> when a programme will start and finish and that this is then used to
> control the recording.  EIT-based timing, such as that described in the
> Nordig document, turns that round.  The scheduler gives an idea when a
> recording will start but the recorder is supposed to listen for EITpf
> and start recording when the programme becomes "now".  It then continues
> to record while EITpf shows it as "now" and stops when it changes.
> Essentially the recorder is in charge rather than the scheduler.
>
> It's not clear that if a programme overruns by, say 10 minutes, the time
> information in the EIT table will show the change.  Rather the programme
> will just continue to show as "now".  It's difficult to be certain.
> I've been logging the results of using my patch to extend recordings for
> several years and might be able to find some examples where recordings
> have overrun.  My impression is that in the UK EITpf timing is accurate
> to the second on the BBC, ITV and some of the other channels.
>
> David
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org