[mythtv-users] everyday i have to make sure myth worked the day before

[jedi]

On Fri, Apr 01, 2011 at 12:36:21PM -0400, Brian J. Murrell wrote:
> On 11-04-01 07:40 AM, Mark Lord wrote:
> > 
> > When I first set up Mythtv (0.18, I think, years ago), the back-end would
> > mysteriously die from time to time, resulting in missed recordings.
> 
> Oh but would it only be as basic as a "just dies" issue.  Those are
> relatively easy to solve,
> 
> > I don't know if it still does that today (0.24), because I added a "nanny"
> > task to babysit the back-end, and restart it whenever it dies abnormally
> > (but not for SIGTERM or SIGQUIT, system shutdown).
> 
> Right.  An easy workaround for that kind of problem to be sure.  Almost
> just as easy to fix the actual problem too though.
> 
> But my problem is not a mythbackend that just dies but rather one that
> continues to live but is deadlocked and doesn't record and/or doesn't
> communicate with frontends necessitating a restart of the backend
> process to "right" it.
> 
> In one example the backend log reports:
> 
> 
> 2011-03-30 20:00:20.502 MythCoreContext: Connecting to backend server:
> 10.75.22.
> 2:6543 (try 1 of 5)
> 2011-03-30 20:00:20.553 MythCoreContext: Connecting to backend server:
> 10.75.22.2:6543 (try 1 of 5)
> 2011-03-30 20:00:27.503 MythSocket(9c167a8:11): readStringList: Error,
> timed out after 7000 ms.
> 2011-03-30 20:00:27.504 Protocol version check failure.
>                         The response to MYTH_PROTO_VERSION was empty.
>                         This happens when the backend is too busy to
> respond,

...I got this recently when one of my recording drives died and I had to 
rebuild the LVM that my recordings sit on. I initially created a 2G file
system.

   Apparently MythTV doesn't tolerate this very well... '-)

[deletia]

   If things are really bad, run the mythbackend from a terminal session
and include useful logging so that you can see when things go wrong. Some
times you just need to do maintenance on these machines.