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

[Chris Pinkham]

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");

        VERBOSE(VB_JOBQUEUE, LOC +
                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.

> Chris Pinkham suggested an approach for the patch, and I've developed it. 

Once you get a patch ready, you can open a ticket and assign it to 'cpinkham'
and I'll take care of getting it in SVN.  Thanks for working on this.

> I have a couple of questions:
> 
>   1. In mythwelcome, the new string was surrounded in tr(), which I
>      assume is for translation.  Is there any more I need to do?

As long as you surround the string in tr() like you did then you're good.
The .ts and .qm translation files will be updated whenever someone runs
lupdate and lrelease in order to update the translations.  The U.S. English
translation will work fine.

>   2. Chris recently added a schedruntime field to schedule jobs in the
>      future.  I don't currently look at this, but probably should.  If
>      the job is set in the future, I should not consider this job
>      pending. i.e. schedruntime > current-time, then ignore it.  Is
>      that right?

I'd consider it pending if schedruntime is less than X minutes from now.
I think X == 15 sounds good, but others might think we should go up to
30.  It might make sense for the shutdown/wakeup code to start waking up
at the beginning of the JobQueue window if there are jobs that need to be
run, but that is another issue.  I don't use the shutdown/wakeup code
so it doesn't matter as much to me.

>   3. In mythshutdown, my new check is in addition to the existing
>      transcode and commflag test.  In this patch I only do the new
>      check if there is no other activity stopping a shutdown.  This is
>      to stop mythwelcome showing two status strings.  e.g. "busy
>      transcoding" and "has running or pending jobs".   Is this OK? 
>      What do you think is the best approach here?   If a transcode or
>      commflag is running, then this new check doesn't do anything new. 
>      If these aren't running, the new check can pickup jobs about to
>      start ... or running user jobs.

On this one, I'll defer to someone else who is more familiar with this
code.  It might make sense to print out all reasons why we won't
shutdown, so people don't have to keep checking to see "why won't it
shutdown _now_, the (only known) issue seems to have been resolved?"
It's like re-running make over and over to fix each additional bug
that is found.  I like to see as many as I can at one time so I can
fix them all. :)

--
Chris