[mythtv-users] Two nagging issues remain.

[Jon]

Yeechang Lee wrote:
> 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.)

Agreed, that is what I am seeing and suspected.
> 
> 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 machine was gigabit.  I noticed playback on the frontend
suffered during comflagging/transcoding.  The nic in the backend
couldn't keep up, many dmesg errors.  I upgraded to gigabit on the
backend and it seemed to help commflagging a completely resolved the
playback issues.  Backend has 2gb ram, dedicated 3 disk strip, and cpu
usage hovers around %50.  I'm not sure what else I can do to help it.
> * 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.
I've not had mythjobqueue crash a single time so I won't worry about that.
> 
> 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.
Ditto.

Thanks,
Jon