[mythtv-users] SBE's mythjobqueue preventing MBE idleness

[Michael T. Dean]

On 04/28/2011 04:50 PM, Michael T. Dean wrote:
> On 04/28/2011 09:57 AM, Brian J. Murrell wrote:
>> Per another thread, I have stopped the mythbackend process on my
>> tuner-less SBE (it's only supposed to lend it's CPU cycles to
>> commflagging) since it's an unsupported configuration and instead
>> started mythjobqueue (with -v most for interest's sake).
>>
>> The problem is that it seems to be keeping the MBE from going into
>> idle-shutdown (i.e. suspend) mode.  Since starting mythjobqueue my
>> backend has not gone into idle mode yet within less than a second of
>> stopping mythjobqueue it started it's idle processing:
>>
>> On the SBE:
>>
>> 2011-04-28 09:51:14.975 JobQueue: GetJobsInQueue: Ignore 'Flag
>> Commercials' Job for chanid 1045 @ 20110428073000 in Finished state.
>> ^C
>>
>> On the MBE:
>>
>> 2011-04-28 09:51:41.316 I'm idle now... shutdown will occur in 300 seconds.
>>
>> Yes, the MBE's timestamp is .6 of a second earlier than the SBE.  Well
>> within the margin of error for this network AFAIC.
>>
>> Is this a known limitation of mythjobqueue?
>    From my perspective, it is now a known limitation of
> mythjobqueue--before it was just a limitation of mythjobqueue.  Thanks
> for noticing.  This is something that needs reworking before 0.25.
>
> In the meantime, we might be able to do some workarounds.  The one I
> think is probably the best/safest is to write a script that can be
> called on a loop (either the script that starts (and backgrounds)
> mythjobqueue, or in a cron job or whatever), and checks to see if the
> jobqueue host is currently processing any jobs (and/or whether any jobs
> are left to process).  If not, it can kill the mythjobqueue process--and
> could also shut down the job queue host, if you want.
>
> The best way to check would be to use the Python bindings' Job class to
> get the status and hostname attributes.  If the status is Job.RUNNING
> and the hostname is the mythjobqueue (current) hostname, then it's not
> safe to kill mythjobqueue/shut down the job queue host.
>
>
> http://www.mythtv.org/wiki/0.24_Python_Bindings
>
> If no one else does it before, I'll try to get a chance to look into
> this over the weekend.

Sorry for the late reply, but here's a script you can use.  Feel free to 
write up some example script code showing how to use it in a 
mythjobqueue start script or a sample script code to run in cron that 
checks status and kills mythjobqueue (or shuts down the mythjobqueue host).

http://www.mythtv.org/wiki/job_queue_idle.py

The exit status is the number of jobs available for processing on this 
host.  I didn't check to see whether you've enabled, "Run jobs only on 
original recording backend," (if not, then in theory, you wouldn't be 
able to use mythjobqueue for processing jobs since without a 
mythbackend, you wouldn't have any jobs for this host).  I also didn't 
check to see whether the job type is allowed on this host--so, if you 
have jobs that are not allowed to run on the mythjobqueue host still in 
the queue and unclaimed by (not processing on) another host, the script 
will still say there are jobs available until some host takes the last 
of those jobs.  But, it's definitely a good start, and can be improved 
by anyone who wants.

Mike