[mythtv] Auto shutdown occurs while transcode/commflag job is in progress (bad idle detection)

[Matt Doran]

Chris Pinkham wrote:
>
>> If I were to develop a patch for this, how does this sound:
>>
>>     * Add a new test to GetStatus() to check for pending jobs (if not in
>>       the job window, we treat it like no jobs are pending)
>>     * Return status "32" (currently not used) to indicate there are jobs
>>       pending.
>>     
>
> Sounds OK to me, but I'm not the mythshutdown guy (I'm the JobQueue guy).
>
> If you make a patch, can you put the logic inside a new method inside the
> JobQueue class?
>
> I'm thinking something like this:
>
> 	static bool JobQueue::HasPendingJobs(bool checkWindow = true)
>
> If HasPendingJobs is static then you can just call it as
> "if (JobQueue::HasPendingJobs())" inside the status check code.
>
> If we call it as JobQueue::HasPendingJobs(false) then it can tell us if
> there are any pending jobs at all, whether we are inside the window or not.
>
> You probably should make it so that the window check checks to see if the
> window is about to start also, because there's no reason to shutdown if the
> window starts in 15 minutes and we could process the jobs.
>
> You can look at JobQueue::IsJobQueuedOrRunning() to see what I use to check
> to see if a specific job is queued or running.
>
>
>   
Sounds like a plan.   I'll give it a go when I get some time.

Another question.  What do you think about the current approach of the 
backend counting down to shutdown when "idle", and only then checking if 
shutdown is allowed (which restarts the countdown).   You might be 
transcoding things for hours ... but this process happens over and over.

To me it seems a bit backwards ... it might be better to do it the other 
way around.  Only start the idle count-down when the backend really is 
idle (no jobs running, no pending jobs).

I think the problem with this code is the confusion between idleness and 
other shutdown checks.   The backend is considered idle when there are 
no recordings are in progress or no clients are connected .... and the 
shutdown check performs a variety of checks (looks for transcode and 
commflag jobs, checks the wake up periods, etc, etc).    It would 
probably be cleaner if we had a clearly separate these 
concepts/responsibilities.    The backend could consider running/queued 
jobs when doing it's idle checks.   The mythshutdown checks could stick 
to the wake periods, etc, etc.

I know this is a pretty tricky area and don't know that there are easy 
answers.  It just seems a bit messy at the moment. <shrug>

Maybe the first step in the right direction is to modify the scheduler 
to peek into the job queue when determining if it's idle?

Thanks for your help,
Matt