[mythtv] Adding RunningStatus information to DVB EIT processing

[Roger James]

On 1 September 2016 10:29:13 a.m. Stuart Auchterlonie 
<stuarta at squashedfrog.net> wrote:

> On 31/08/16 18:12, roger wrote:
>>
>>
>> On 31/08/16 14:53, Stuart Auchterlonie wrote:
>>> On 31/08/16 14:19, roger wrote:
>>>>
>>>> On 31/08/16 08:36, David Matthews wrote:
>>>>> On 24/08/2016 18:23, Roger James wrote:
>>>>>> I had quick look at David's patch. Has has added EIT parsing to
>>>>>> tv_rec.
>>>>>> My feeling is that the maintenance of our copy of the EIT table object
>>>>>> should be kept in eitscanner and that should pass on internal EIT
>>>>>> status
>>>>>> changes to the scheduler and if required to the active recorders as
>>>>>> well.
>>>>>>
>>>>>> The EIT stuff is complex already and spreading it further seems to
>>>>>> me a
>>>>>> bad design decision.
>>>>>>
>>>>>> My thinking at the moment is a two stage implementation firstly to
>>>>>> sort
>>>>>> out handling of running status information in the EIT table object
>>>>>> itself. Then at a later stage add parsing of the running status
>>>>>> table to
>>>>>> get more timely running status information.
>>>>> I'd consider my patch as a proof-of-concept rather than anything else.
>>>>> I'd be the first to agree that it could be done better but I wanted to
>>>>> minimise the changes.  I've been using this for a number of years and
>>>>> wouldn't do without it.  The "bookmark on start" means that playback
>>>>> almost always starts exactly at the start of the programme and the
>>>>> "extend until finished" means the end of a programme isn't lost if it
>>>>> overruns.
>>>>>
>>>>> I did find a few problems with the EIT collection and I don't think
>>>>> all of them are fixed by my patch.  In some circumstances,
>>>>> particularly with channel changes, EIT collection stops.  That's
>>>>> obviously not an issue if it's just being used to populate the listing
>>>>> information but would need to be fixed for continuous running status.
>>>>>
>>>>> The other issue with "extend until finished" that I never really
>>>>> addressed is that affects scheduling since there's always the
>>>>> possibility that the scheduler might have lined up a recording on
>>>>> another channel for that tuner.
>>>>>
>>>>> Let me know if I can be of any help.  It would be lovely to be able to
>>>>> ditch my patch in favour of having it done properly in Myth.
>>>>>
>>>>> Regards,
>>>>> David
>>>>>
>>>> Hi David,
>>>>
>>>> Thanks for the response. My brain starts hurting every time I look at
>>>> the EIT code! I had some discussions with Stuart and dekarl about EIT
>>>> handling a while back (bug #11399) and I eventually made the the same
>>>> decision that you made and went with my own cleanup patch.  I have some
>>>> time now to tackle the issues again. I think I will attempt to clean up
>>>> the DVB EIT handling first. The later issues of ETSI EN 300 468 and ETSI
>>>> ETR 211 have clarified things a bit. Some of the things we are doing are
>>>> just plain wrong, but fortunately harmless.
>>> Hi Roger,
>>>
>>> What sort of cleanup do you have for EIT data. I'm sure there are some
>>> cleanups that can be done, and i'm open to improving EIT further.
>>>
>>> Regards
>>> Stuart A
>>>> Are you using DVB eit tables or one of the of the other variants (ATSC
>>>> etc.)? If you are using DVB does your network transmit the Running
>>>> Status Table. I have yet to catch one here in the UK ( however my
>>>> antenna on my test system is a piece of wet string hanging out of the
>>>> window!).
>>>>
>>>
>> 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