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

[David Engel]

On Wed, Feb 08, 2023 at 05:49:34PM +0000, Ian Cameron wrote:
> 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.

But I still might!  Someday.  When I have a better solution to the
misuse.  I've never bought the "my guide data is bad" argument and I
still don't.  In the immortal words of Steve Jobs, "You're doing it
wrong?" :)

Either you care about catching the beginning or ends or your
recordings or you don't.

If you do care, you should use the start early/end late options.
That's what they are for(*).  If there is a conflict, wouldn't you
really rather have the scheduler choose a later showing that woh't get
chopped off?  IMO, that's much better hoping that the tetris blocks
just happen to fall in perfect way by accident.  If there is a
conflict, the scheduler will tell you so that YOU can make the best,
informed decision on what to do.

If you don't care about your recordings getting chopped off, then
what's the beef?  Okay, so you really do care, at least some and want
oportunistic lengthening of recordings.  I think that's the wrong
approach.  I think it would be better to apply oportunistic
shortening, mainly at the beginning, where the recording rule
explicitly specifies how much shortening is acceptable.

David

(*)FWIW, the scheduler already has the ability increase the likelyhood
that recordings on the same channel/multiplex that can safely overlap
will overlap.  More people should take advantage of that

> 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

> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


-- 
David Engel
david at istwok.net