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

[David Engel]

On Wed, Feb 08, 2023 at 09:09:07PM -0600, David Engel wrote:
> 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.

Also, how many of you that claim you must have long pre- and
post-rolls have actually tried using start early/end late instead?  I
suspect most of you would get by just fine.

David

> 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

-- 
David Engel
david at istwok.net