[mythtv] Adding RunningStatus information to DVB EIT processing

[Stuart Auchterlonie]

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