[mythtv] [PATCH] Stop automatic shutdown when jobs still pending (or user jobs running)

Matt Doran matt.doran at papercut.biz
Sat Apr 28 08:07:28 UTC 2007

Chris Pinkham wrote:
> Sorry for not responding to the other thread quickly.  I'm glad you went
> ahead with this.
> * On Tue Apr 24, 2007 at 11:08:07PM +1000, Matt Doran wrote:
>> This is my first patch to myth, so be gentle.   :)     The issue that 
>> this patch solves is discussed in the thread: "Auto shutdown occurs 
>> while transcode/commflag job is in progress (bad idle detection)"
> Glancing over this, I think that this looks good so far.  I think I would
> like to keep the debug statements in that print out the window start/end
> times.  They will only ever be executed when we run with "-v jobqueue",
> and the settings values are cached, so I think it's OK to change them
> to something like the following instead of removing the start/end times
> from the debug statements:
>     if (print_verbose_messages & VB_JOBQUEUE) {
>         queueStartTimeStr =
>             gContext->GetSetting("JobQueueWindowStart", "00:00");
>         queueEndTimeStr =
>             gContext->GetSetting("JobQueueWindowEnd", "23:59");
>                 QString("Currently set at %1 job(s) max and to run new jobs "
>                         "from %2 to %3").arg(maxJobs).arg(queueStartTimeStr)
>                                         .arg(queueEndTimeStr));
>     }
> That way when running in debug mode we can still see the window times
> even though you've moved out the actual logic into JobQueue::InJobRunWindow().
> I can't remember if we talked about it or not in the other thread, but
> we probably shouldn't allow shutdown if jobs would be run in the next X
> minutes.  I think X could be 15 or 30 minutes.  The code probably should
> take that into account.  If we check for shutdown at 7:55 and the run window
> doesn't start until 8:00, then we might shutdown when we should probably
> have stayed up to run those jobs and then shutdown.  This same logic holds
> true for the schedruntime, if there are jobs that are 'scheduled' to run
> in the next X minutes and that is inside the window, then we should stay
> up as well instead of shutting down.
Hi Chris,

I've had another go at the patch.   The major changes from the previous 
patch are:

1. The InJobRunWindow() method, now takes an optional argument 
"orStartingWithinMins".  If this is > 0, we check to see if the job 
queue window starts within that time.

2. Change the InJobRunWindow() method to use QTime objects, so I could 
do real time arithmetic.

3. The HasRunningOrPendingJobs() method, now takes an optional argument 
"startingWithinMins".  If this is > 0, we'll look for jobs pending to 
start within this time.  It only considers a job pending if, we're in 
the job run window (or it starts within that time) and there are pending 
job's who's schedruntime is within this time.

4. The mythshutdown status now runs my running/pending check, even if it 
finds a transcode job running.

One additional question, I've hard-coded the 15 minutes value in 
mythshutdown.  Should this be a config value or would that be 
overkill?   There's another 15 minute hard-coded value in mythshutdown 
(wake up period about to start), so it's probably not a big deal.

If you think it looks ok, I'll raise a issue in trac for this.

Thanks again,

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: shutdown-jobs.diff
Url: http://mythtv.org/pipermail/mythtv-dev/attachments/20070428/c017b339/attachment.diff 

More information about the mythtv-dev mailing list