[mythtv-users] Slave Backend requirements

[Michael Watson]

On 22/08/2013 7:29 AM, Michael T. Dean wrote:
> 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.
2 Gig RAM - Running FE and SBE - No Swap being used.  Not concerned 
about memory usage at this point.

mythbackend[1938]: I Scheduler scheduler.cpp:2207 (HandleReschedule) 
Scheduled 609 items in 5.0 = 0.00 match + 0.00 check + 5.00 place
Not concerned about the time the scheduler takes to run.

>
>>>
>>> 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.
It is clear that many developers do not run a SBE, as there is an issue 
for some time that causes the MBE to segfault when a SBE is connected 
(often when it first connects, also at other times I believe when the 
SBE queries the MBE for the amount of free space in a storage group) - 
No there isnt a ticket raised for this in 0.27 as I had assumed 
http://code.mythtv.org/trac/ticket/11318 was the related ticket, but JYA 
recently advised that this is a ticket for 0.26.  Time permitting I will 
investigate further and open a ticket for 0.27 - but I do find the 
creation of a ticket rather cumbersome...

Idle shutdown of MBE/SBE works well, and works perfect for a SBE that is 
used for no other purpose.  It fails miserably when used with a SBE/FE.  
I use the sleep trigger from the MBE to run a script on SBE/FE that 
checks and waits for the FE to become idle before shutting down.  As the 
MBE will only tell a SBE to shutdown once (and assumes that it will do 
what it is told), this script must also check that the SBE is not 
schedule to record in the near future, or that it is not performing any 
commflag/transcoding/userjobs.  NOTE: This is not a complaint, just 
advice on the pitfalls of using a SBE/FE machine to autoshutdown on 
idle. My setup works well for me, whilst working with the tools 
available within myth to achieve my desired outcome.
     The fact that Myth has the ability to run remote FE and SBE's, and 
the flexibility this provides leaves it many miles ahead of any other 
software and/or propriety hardware setup available, nothing even comes 
close - (The way I use it anyway)

>
> 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.
With uBuntu packages, each time the mythtv-backend package is updated, 
the init script is re-enabled.  As currently the mythjobqueue binary is 
located in the mythtv-backend package, you need mythtv-backend package 
installed to run mythjobqueue.  So, if you disable mythtv-backend from 
starting, and an init script for mythjobqueue, this is broken each time 
you upgrade packages.  Which causes headaches, and reduces 
simplification of setup up a machine to shutdown when not in use, one of 
the reasons I took this approach.  When I tried to use mythjobqueue I 
found it unreliable.



>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users