Mailing List Archive

Adding RunningStatus information to DVB EIT processing
Hi StuartA, Dekarl, et al.

Have any of you guys been thinking more about adding DVB Running Status
information to our EIT processing. In some discussions on EIT tables we
had a long time ago, I mentioned that I was thinking of looking into it.
It has got to the top of my list again :-)

Running Status is used in a number of areas of the DVB spec, but the one
of interest is the running status contained in the EIT. This gives the
on air status of an EIT entry.

0 - undefined
1 - not running
2 - starts in a few seconds
3 - pausing
4 - running
5 - service off air
6,7 - reserved for future use

So I think it might be a good idea to use the scheduled start time from
the EIT to cold start the backend (idle shutdown/wakeup) and the running
status to start the recording or stop recording. State 2 is specifically
provided for this purpose. State 3 is intended for multi part events
e.g. a long film interrupted by the news (It may also be useful for
marking commercial breaks).

DVB also provides a Running Status table. This table is intended to
provide near real time updating to the running status field of
individual EIT entries.

I have more thoughts on this, but I would like get feedback first.

Any comments?


Roger


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
On 24/08/16 16:29, roger wrote:
> Hi StuartA, Dekarl, et al.
>
> Have any of you guys been thinking more about adding DVB Running Status
> information to our EIT processing. In some discussions on EIT tables we
> had a long time ago, I mentioned that I was thinking of looking into it.
> It has got to the top of my list again :-)
>
> Running Status is used in a number of areas of the DVB spec, but the one
> of interest is the running status contained in the EIT. This gives the
> on air status of an EIT entry.
>
> 0 - undefined
> 1 - not running
> 2 - starts in a few seconds
> 3 - pausing
> 4 - running
> 5 - service off air
> 6,7 - reserved for future use
>
> So I think it might be a good idea to use the scheduled start time from
> the EIT to cold start the backend (idle shutdown/wakeup) and the running
> status to start the recording or stop recording. State 2 is specifically
> provided for this purpose. State 3 is intended for multi part events
> e.g. a long film interrupted by the news (It may also be useful for
> marking commercial breaks).
>
> DVB also provides a Running Status table. This table is intended to
> provide near real time updating to the running status field of
> individual EIT entries.
>
> I have more thoughts on this, but I would like get feedback first.
>
> Any comments?
>
>

There has been some work done on this already by David Matthews.
See https://code.mythtv.org/trac/ticket/10101

Might be a good starting point?


Regards
Stuart


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
Hi Stuart,

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.

Roger

Roger


On 24 August 2016 4:46:21 pm Stuart Auchterlonie <stuarta@squashedfrog.net>
wrote:

> On 24/08/16 16:29, roger wrote:
>> Hi StuartA, Dekarl, et al.
>>
>> Have any of you guys been thinking more about adding DVB Running Status
>> information to our EIT processing. In some discussions on EIT tables we
>> had a long time ago, I mentioned that I was thinking of looking into it.
>> It has got to the top of my list again :-)
>>
>> Running Status is used in a number of areas of the DVB spec, but the one
>> of interest is the running status contained in the EIT. This gives the
>> on air status of an EIT entry.
>>
>> 0 - undefined
>> 1 - not running
>> 2 - starts in a few seconds
>> 3 - pausing
>> 4 - running
>> 5 - service off air
>> 6,7 - reserved for future use
>>
>> So I think it might be a good idea to use the scheduled start time from
>> the EIT to cold start the backend (idle shutdown/wakeup) and the running
>> status to start the recording or stop recording. State 2 is specifically
>> provided for this purpose. State 3 is intended for multi part events
>> e.g. a long film interrupted by the news (It may also be useful for
>> marking commercial breaks).
>>
>> DVB also provides a Running Status table. This table is intended to
>> provide near real time updating to the running status field of
>> individual EIT entries.
>>
>> I have more thoughts on this, but I would like get feedback first.
>>
>> Any comments?
>>
>>
>
> There has been some work done on this already by David Matthews.
> See https://code.mythtv.org/trac/ticket/10101
>
> Might be a good starting point?
>
>
> Regards
> Stuart
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
On 24/08/16 18:23, Roger James wrote:
> Hi Stuart,
>
> 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.
>

That sounds like a very good idea

> 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.
>

Good plan


Regards
Stuart


> Roger
>
> Roger
>
>
> On 24 August 2016 4:46:21 pm Stuart Auchterlonie
> <stuarta@squashedfrog.net> wrote:
>
>> On 24/08/16 16:29, roger wrote:
>>> Hi StuartA, Dekarl, et al.
>>>
>>> Have any of you guys been thinking more about adding DVB Running Status
>>> information to our EIT processing. In some discussions on EIT tables we
>>> had a long time ago, I mentioned that I was thinking of looking into it.
>>> It has got to the top of my list again :-)
>>>
>>> Running Status is used in a number of areas of the DVB spec, but the one
>>> of interest is the running status contained in the EIT. This gives the
>>> on air status of an EIT entry.
>>>
>>> 0 - undefined
>>> 1 - not running
>>> 2 - starts in a few seconds
>>> 3 - pausing
>>> 4 - running
>>> 5 - service off air
>>> 6,7 - reserved for future use
>>>
>>> So I think it might be a good idea to use the scheduled start time from
>>> the EIT to cold start the backend (idle shutdown/wakeup) and the running
>>> status to start the recording or stop recording. State 2 is specifically
>>> provided for this purpose. State 3 is intended for multi part events
>>> e.g. a long film interrupted by the news (It may also be useful for
>>> marking commercial breaks).
>>>
>>> DVB also provides a Running Status table. This table is intended to
>>> provide near real time updating to the running status field of
>>> individual EIT entries.
>>>
>>> I have more thoughts on this, but I would like get feedback first.
>>>
>>> Any comments?
>>>
>>>
>>
>> There has been some work done on this already by David Matthews.
>> See https://code.mythtv.org/trac/ticket/10101
>>
>> Might be a good starting point?
>>
>>
>> Regards
>> Stuart
>>
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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.

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!).

Roger
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
On 31/08/2016 14:19, roger wrote:
> 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.
>
> 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!).
>

I'm in the UK too; well, Scotland. I only ever attempted to use EITpf
to switch the status. As far as I can tell in the UK the FreeView+ and
FreeSat+ recorders use this. I have a feeling that the UK standards
aren't freely available but the Nordig standard, which is probably
identical, is available at
http://nordig.org/wp-content/uploads/2016/04/NorDig_PVR_metadata_whitepaper_ver_1.0.pdf
.
This does say that EIT p/f is used.

Regards,
David
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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!).
>
> Roger
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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.

Roger
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
On 1 September 2016 10:29:13 a.m. Stuart Auchterlonie
<stuarta@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



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
>>> 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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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@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@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
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@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@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Adding RunningStatus information to DVB EIT processing [ In reply to ]
Hi David, Stuart, Karl, etc.

This is update on where I am at. I will not have direct access to my
development system for a week.

I have started to implement a testbed. It is very rudimentary at the
moment. You can find it here https://github.com/rogerjames99/mythtv .
The files of interest are mythtv/libs/libmythtv/eitcachedvb.cpp and
eitcachedvb.h.

I am still working on a robust way of handling the SI EIT tables. The
current thing I am thinking about is how to handle discontinuities in
the PF table. I receive PF sections from whatever transport stream is
tuned at the time (I think there could/should be more than one). The
section update has a PID that tells me this update has been received on
the "actual" transport stream and network the it refers to, or from an
"other" transport stream and network. Both of these are referring to the
same table object which is identified by the transport_stream_id and
original_network_id contained in the table section data itself (not to
be confused with the fields of the same name in other SI tables). So if
I receive a version_number on the "actual" I can guarantee that this is
the current_version_number and the table is up to date at this moment.
However I may not have have seen any sections for this table object from
its actual stream. So in this case I have to rely on "other" streams. If
this is a newly created instance of this table object then I can use
"other" stream data as a best guess without any further checks. However
if I currently have a version number which may be from an "actual" or an
"other" stream I need a robust algorithm to determine which version is
the most recent, my current one or the one I have just received, bearing
in mind that the version number is modulo 32.

To help me do this I have already decided to store a flag that tells me
whether that current_version_number I have is from an "actual" stream or
not. I am thinking about using information from the "present" or
"future" events themselves to make a better informed guess. The things
in these events that might be useful are the event times and the running
status.

I am looking for ideas on the algorithm.

I currently have a blank sheet of paper!

Roger


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org