[mythtv] new job status: JOB_CANCELLED

[Brad Benson]

I'm looking into adding the ability to manually start/stop jobs for
all recordings in a playlist (see my post - Manual Job Scheduling for
Playlists) and in my work towards that goal have realized that we may
want to make a slight change to the way the job queue currently
handles stop commands.

To my understanding the way the queue currently works is that jobs
that have never been run but receive a JOB_STOP command will not
received that JOB_STOP command until after they have been started. 
This would mean that if you have 20 jobs queued and send a stop
command to all of them they would each be started and then immediately
stopped on the next processing of the job queue.  For standard jobs
like transcoding and commflagging this isn't a huge deal other than
the waste of overhead to start each job unnecessarily and then stop
it, but for user jobs we can't guarantee that they'll even check the
job queue for stop commands.  In that case user jobs would still be
run even though they were sent stop commands before they began
execution.  In addition, it could greatly increase the delay before
running jobs depending on the user's settings.  For instance, I have a
single backend that is only allowed to run one job at a time and
checks the job queue every 60 seconds.  In the above example one of
the stopped jobs would be run every 60 seconds for 20 minutes and then
stopped 60 seconds later when the next job would be started.  So any
other jobs still scheduled to be run would not start for at least 20
minutes until those stopped jobs got cleared out of the queue.

What I propose is that we add a JOB_CANCELLED status (this was
actually Chris Pinkham's idea) and that the job queue would determine
at processing time whether to apply a JOB_STOP command (if the job is
already running) or to set the job status to JOB_CANCELLED (if the job
is still queued and not yet started).  This would prevent the
stopped-before-starting jobs from eating up queue processing cycles
and, for non-stoppable user jobs, prevent them from running even
though the stop command was sent.

This is a very simple change to make and I will gladly submit a patch
if this change is acceptable to the other developers.

I'd also like to dig a little deeper into the code and possibly
contribute some more useful features/fixes to the project, but I've
just signed onto the -dev list and started digging into the code over
the past few weeks so please be gentle if I've made any mistakes here.
:)

Anyway, I've been using myth for almost 2 years now and love it so I
figured it's about time to start giving something back.  Let me know
what you guys think of this and I'll get a patch in soon if it's
acceptable.

Brad