[mythtv-users] Two nagging issues remain.
ylee at pobox.com
Sun Mar 18 22:41:23 UTC 2007
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.)
* 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
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
More information about the mythtv-users