[mythtv-users] Two nagging issues remain.

[Yeechang Lee]

Jon <jon at sd-6.org> says:
> I have 3 boxes in the mix, one is my backend, one is the frontend, a
> third dedicated to mythjobqueue.  The problem is that commercial
> flagging mostly fails.  It seems to be stopping prematurely.
> Sometimes it will make it to the first commercial break, sometimes
> not.  Some shows actually seem more reliable than others.  It
> typically fails with a bunch of mpeg2video errors (may not actually
> be failing here) or, and more likely failing with "waiting x seconds
> for data to become available).

In my experience mythcommflag is very, very, very vulnerable to any
hiccups while reading a recording. I first noticed this when (for
various reasons) running a mythcommflag process within a VMware
virtual machine. The added latency from doing so caused mythcommflag
to almost always die early after a "waiting x seconds" error
message. (I think two seconds is all it takes.)

Two suggestions:

* Improve network performance between wherver you store recordings and
  the machine mythjobqueue runs on. This means looking at both the
  network throughput and the loads on both boxes.
* mythjobqueue has an annoying tendency to die when mythcommflag does,
  so run mythbackend instead. Slave mythbackends run fine wihtout
  tuner cards; they only complain once at startup about not having any
  tuners.

And, for developers:

* Please increase the size of the timeout mythcommflag can handle
  before dying to something like 10 seconds. mythtranscode isn't
  vulnerable to brief hiccups the way mythcommflag is.

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US