[mythtv] Auto shutdown occurs while transcode/commflag job is in progress (bad idle detection)
matt.doran at papercut.biz
Mon Apr 16 01:21:16 UTC 2007
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
> 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,
More information about the mythtv-dev