[mythtv-users] Slave Backend requirements

Michael T. Dean mtdean at thirdcontact.com
Wed Aug 21 21:29:35 UTC 2013


On 08/21/2013 05:16 PM, Michael Watson wrote:
> On 21/08/2013 11:07 PM, Michael T. Dean wrote:
>> On 08/20/2013 10:34 PM, Michael Watson wrote:
>>> I run my Frontends as SBE (with a configured Dummy Tuner) to assist 
>>> with commercial detection, whilst I know I can use mythjobqueue to 
>>> achieve this, with Mythjobqueue the SBE/Frontend will not shut down 
>>> whilst not in use, mythjobqueue is great for a 24x7 system.
>>
>> I'm not sure what, specifically, you mean by this, but since Feb 2012 
>> mythjobqueue only holds a blocking connection when it's actually 
>> processing jobs, but changes to a non-blocking connection (which 
>> allows master backend shutdown) when it's idle.  (This has been in 
>> releases since 0.25.)
>>
>> http://www.gossamer-threads.com/lists/mythtv/commits/502795#502795
>>
>> So a mythjobqueue server won't prevent the master backend from 
>> shutting down, unless it's actually running a job (which requires 
>> master backend presence/availability).  And a mythjobqueue server 
>> will take significantly less resources than a remote backend.
> I would say that the difference in resource usage between the two is 
> significant.  Yes there is a difference in resource usage between the 
> two.

It's about 1/10th the memory, if nothing else.  And, it doesn't make the 
scheduler run slower (by adding dummy tuners) and doesn't require 
putting useless dummy tuners in place.

>>
>> If you're saying that the master backend won't send out a message 
>> telling the mythjobqueue system to go to sleep, that's true, but then 
>> again, that's only useful on a machine with tuners that the master 
>> backend may decide to use at some time that the remote backend can't 
>> predict.  On a machine that doesn't have tuners that may be needed at 
>> some unknown point in the future, the machine can simply shut down 
>> when it desires.  So, you could use the frontend idle shutdown 
>> capability or mythshutdown to shut down the computer when idle.
>>
>> I don't know if mythfrontend's idle shutdown capability checks job 
>> queue status, but I know mythshutdown does, so you may need to use 
>> mythshutdown.
>
> I found mythshutdown next to useless in a MBE/SBE scenario, it only 
> returns "OK" when all tuners are idle (and not required in the near 
> future), so a slave backend will not shutdown until the MBE's tuners 
> are idle.  On a SBE/FE mythshutdown will allow the BE's to shutdown 
> whilst watching a recording/video or listening to music - ie totally 
> ignores the FE running on the same machine.

You said you were running a remote mythbackend on a system with only 
dummy tuners.  So if mythshutdown doesn't work on a remote mythbackend, 
we're back to the original recommendation--don't run mythbackend and run 
mythjobqueue.

That said, AIUI, mythshutdown is not for use on remote 
backends--instead, you need to tell the master backend to "sleep" the 
remote backends.  I.e. it decides when to shut down remote backends, 
because it knows what tuners are required, and it sends a message to the 
remote backend telling it to sleep (or shut down or whatever your script 
does to it).  I'll admit a) I haven't played with it and b) it's a huge 
mess of 3 1/2 separate mechanisms added and extended over time, so it 
could be improved significantly.

I still think automatic shutdown should be very much usable with 
mythjobqueue systems on 0.25+, though.  A mythjobqueue system--because 
it doesn't do all things a backend does, such as dealing with tuners 
needed on a schedule--is much simpler and should be much simpler to set 
up to shut down.

Mike


More information about the mythtv-users mailing list