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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
