[mythtv] Adding RunningStatus information to DVB EIT processing

David Matthews dm at prolingua.co.uk
Fri Sep 2 12:02:44 UTC 2016


Hi Roger,
Yes.  That actually gives more precise information than the document I 
was looking at, the PVR metadata whitepaper.

David

On 02/09/2016 12:24, Roger James wrote:
> 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
>


More information about the mythtv-dev mailing list