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

[Craig Sanders]

On Fri, Jan 09, 2009 at 12:29:49PM -0500, Michael T. Dean wrote:
> 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.

good.  so that means it works fine, just wastes memory?


> 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 ...

well, there's a few USEFUL command-line args that mythbackend supports
that mythjobqueue doesn't:

1. --daemon
2. --pidfile
3. --logfile

the first is essential for any program intended to be run as a daemon.
the second two aren't quite essential but are very close.

without them, mythjobqueue is not a drop-in replacement for mythbackend.

i've been modifying the /etc/init.d/mythtv-backend script (from the
debian-multimedia mythtv packages) on my system for the last half
hour. the lack of a --logfile option in particular makes this far more
complicated than it needs to be. actually, the lack of a --logfile arg
for mythjobqueue has made me abandon the effort because it's not worth
doing.

'--daemon' and '--pidfile' can be emulated with start-stop-daemon's
'--background' and '--make-pidfile'. not perfect but so far, so good.
an if/elif/fi block can set appropriate args for start-stop-daemon
depending on which "daemon" (mythbackend or mythjobqueue) is being run.

but --logfile can't be emulated with start-stop-daemon. the only way
of handling this is *another* if/elif/fi block for *each* of the stop,
start, restart cases. one for mythbackend without redirection of stdout,
and another for mythjobqueue with redirection.

actually, a better method is to use the shell's exec function to
redirect all further output to a logfile, which is what i've done: 
  'exec > /var/log/mythtv/mythjobqueue.log'

but even that is sub-standard. mythjobqueue doesn't handle the
logfile itself, so logfile rotation will require a restart of
mythjobqueue...with unknown consequences for any currently running jobs.

(actually, it doesn't even seem to work properly. mythjobqueue runs OK
like this, but stdout isn't redirected to the logfile. my guess is that
start-stop-daemon's '--background' arg closes stdout. so there's no
logging at all)


so, 256M may be a high price to pay for those three features but, for
now, it's a price i'm willing to pay. even though i've essentially
finished the job, i'm abandoning my effort to modify the init.d script
to support either mythbackend or mythjobqueue because mythjobqueue
is an inadequate substitute for mythbackend. it seems like a hasty
after-thought rather than a fully-functional replacement.


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

the point of my message that you replied to wasn't about the
functionality, it was about the lack of documentation on this topic.
googling for various unsupported & conflicting opinions in a mailing
list is no substitute for documentation.

and, it turns out that the functionity is lacking too.

craig

-- 
craig sanders <cas at taz.net.au>