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

[David Engel]

On Tue, Feb 07, 2023 at 02:05:35PM +0000, Paul Harrison wrote:
> On 07/02/2023 02:37, David Engel wrote:
> 
> > On Mon, Feb 06, 2023 at 10:04:04PM +0000, Paul Harrison wrote:
> > > On 06/02/2023 21:27, Klaas de Waal wrote:
> > > 
> > > > There is the constant kSleepCheck = 300 and this is the maximum number of
> > > > seconds to wait between scheduler runs.
> > > > See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
> > > > Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
> > > > where this was changed from a hardcoded 300 to the constant.
> > > > When kSleepCheck is changed to 30 seconds then there is always one
> > > > REC_PENDING
> > > > in the first time window, from  120 to 90 seconds.
> > > > Paul, do you think that it is a problem for the scheduler to wake up
> > > > every 30 seconds?
> > > > 
> > > I honestly don't know what side effects that would have. I would consult
> > > with David Engel since the scheduler is his baby.
> > Please send me any patches you want considered.  However, sleeping
> > backends is something I've never done nor intend to do.  That is all
> > Chris Murdoch's logic and I usually try to avoid it.  IOW, you all are
> > now probably more versed in it than me.
> > 
> > FWIW, I'd very much like the sleep and wake logic to be moved
> > completely or mostly out of the scheduler proper and into some other
> > component which observes the schedule and acts accordingly.
> > 
> > David
> 
> 
> While it might look like this is related to sleeping backends it's not
> really. It all started on the forum where a user was asking why the
> REC_PENDING and REC_STARTED events were being sent out of order or too close

Okay.  My skimming picked up on the sleeping slave bit as the part
that was new and causing the issue.

> together. Whoever wrote the code shoehorned it into the same code used to
> wake slave backends and I agree ideally it should be separated out. I wont

I don't remember who add the event code.

> speak for Klaas but for me that's a little more involved than I want to get
> into right now.  We just want the scheduler to send out the events in the
> correct order and at the right times.  The correct behavior appears to be to
> sent out REC_PENDING events at 120, 90, 60 and 30 seconds before a recording
> starts, taking any pre-roll into account, and then send a REC_STARTED event
> when the recording actually starts recording. Any thoughts and how to fix
> the scheduler to do that correctly?

I see.  Sounds like one more reason, IMO, to kill user-configurable
pre- and post-roll.  Maybe you all (that's not specifically directed
at any single person) can appreciate the extra, unnecessary complexity
that adds.  I'd much rather fix it at 30 seconds or so and add a new
feature to allow starting some recordings up to so many minutes late.
Yes, I know that horse has been dead for a long time but I still enjoy
beating it.  It makes me feel better.

Anyway, it sounds like one or both of you have something in mind.
Again, please send me the patch when you have one.

What happens, though, if the schedule changes after a REC_PENDING
event is sent?  You're saying to start sending 2 minutes before
pre-roll might start.  With a pre-roll of up to 10 minutes, that means
events could start up to 12 minutes before the actual recording.
That's a lot of time in which things could change.

I ask because I've never paid attention to these events before and
want to better understand their intent and use cases, especially the
pending one.  The schduler has its own pending state that I beleve
starts about 30 seconds but it might be less before the recording.
That is when the schduler commits to using a specific input and that
decision isn't changed except in a couple of very specific cases.

David
-- 
David Engel
david at istwok.net