[mythtv-users] backends without tuners (was Re: Transcoding is being done on frontends, not backend)

Michael T. Dean mtdean at thirdcontact.com
Fri Jan 9 17:29:49 UTC 2009


On 01/08/2009 11:05 PM, Craig Sanders wrote:
> On Thu, Jan 08, 2009 at 03:47:03PM -0800, Brad DerManouelian wrote:
>   
>> The supported method of running jobs on other machines that do not  
>> have tuners is to run mythjobqueue.
>>     
...
> the only mention of mythjobqueue in the manual is a few paragraphs at
> section 23.25 - there's no mention anywhere in the manual that tunerless
> backends are unsupported, or that mythjobqueue should be used instead of
> mythbackend if no tuners are installed.

Note that if you run mythbackend on a host without any configured 
capture cards, all the parts of mythbackend that are not included in 
mythjobqueue are disabled--meaning you're basically running mythjobqueue 
+ cruft.  "What cruft?" you may ask.

# pmap -d `pidof mythbackend`
1683:   mythbackend -d -l /home/mythtv/log/mythtv.log
...
mapped: 335940K    writeable/private: 287712K    shared: 0K


# pmap -d `pidof mythjobqueue`
1702:   /usr/local/bin/mythjobqueue
...
mapped: 144584K    writeable/private: 35284K    shared: 0K

So that's 252428KiB of cruft (287712K - 35284K).  (Using 
writeable/private as mapped includes shared libraries like the MythTV 
libs (and many others) that are already in use by other apps--such as 
mythfrontend.)

Yeah, I realize that 256MiB of RAM isn't too expensive today, but why 
fill it up with garbage you're not using?  Why not use it for something 
useful, like the kernel buffers/cache--or preventing mythtranscode or 
mythcommflag from hitting swap or ...

And, as Brad has mentioned, since it was designed to be used that way, 
it's been tested that way.

Mike


More information about the mythtv-users mailing list