SBE's mythjobqueue preventing MBE idleness

[brian@…]

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?

[sphery]

For 0.24-fixes, users can use an external script, such as http://www.mythtv.org/wiki/Job_queue_idle.py . In the future, a more-integrated solution will be added to MythTV (allowing mythjobqueue to change its connection type allowing shutdown).

[brian@…]

OK. So Job_queue_idle.py exits > 0. I then start mythjobqueue. What stops it when the job queue is empty again? As I understand, once mythjobqueue starts, it continues to run forever, polling the job queue, yes? Do I just keep running Job_queue_idle.py until it exits 0 and then kill the mythjobqueue I started?

[sphery]

Forgot there was a ticket for this. Fixed by 73492e1a :

Allow backend shutdown when mythjobqueue is idle.

This change also adds MythCoreContext::IsBlockingClient?() function to allow querying the current blocking status (whether the connection to the master backend is blocking shutdown or not).

Binary version change, so requires recompiling plugins, etc.