[mythtv-users] Events at the beginning of a recording

Ian Cameron mkbloke at gmail.com
Wed Feb 8 17:49:34 UTC 2023

On Wed, 8 Feb 2023 at 17:19, Klaas de Waal <klaas.de.waal at gmail.com> wrote:

> On Wed, 8 Feb 2023 at 13:55, Ian Cameron <mkbloke at gmail.com> wrote:
>> I thought the same when I read this.  Isn't it the case that a lot of
>> MythTV users will be making use of the user-configurable pre and post roll
>> times?  I know I do.  While UK programming doesn't usually tend to start
>> early, it can do occasionally, so I use a 2 minute pre roll.  A 4 minute
>> post roll in the UK seems to be enough to catch a very high percentage of
>> any late running programmes other than those delayed by sporting events
>> that overrun.  I don't use EIT, so I don't know if that would get updated
>> quickly enough here to adjust recording times for overrunning sports events
>> in any case.
> I do not intend to remove the RecordPreRoll, one good reason being that I
> use it myself. Even with EIT it is useful and MythTV is clever enough to
> put the start point at the scheduled program start time so it is always
> automatically skipped over and I can skip back when it is needed.

Phew!  Thanks.

To summarize, I understand that this are the requirements:
> - REC_PENDING always before the REC_STARTED
> - REC_PENDING at 120, 90, 60 and 30 before the start of the recording
> - Start of the recording is the scheduled program start time plus the
> preroll
> - When a recording is immediately started after scheduling then there is
> one REC_PENDING event with 0 seconds immediately before the REC_STARTED
> I do have a slightly hacky implementation that does all this, it needs a
> bit of cleaning up and more testing.
> This is just a fix, not a rewrite/refactoring. That is something we leave
> for another day.
> I might however make a Github issue for this so that we capture the
> knowledge and not forget.....

If you have the beginnings of a fix, I guess that might be the most
time-efficient way to do things.  What you have listed is pretty much how
things operated in the past I think (I detailed what I see in 0.28
previously in this thread).  I assume then that somewhere there is a commit
that has broken this, which could in theory be identified with a git
bisect, but perhaps that's not worthwhile now.

Thanks for your ongoing work, on behalf of us users.

Cheers, Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230208/0be6b929/attachment.htm>

More information about the mythtv-users mailing list