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

[Paul Harrison]

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


Paul H.