[mythtv-users] Tuning oddness - errors in log - ivtv or mythtv?

[Rich West]

Rich West wrote:
> I've hit this twice in the past two weeks, but quite suddenly, we will
> have troubles watching tv (yes, every now and then, that option does
> actually get used) because it thinks all of the tuners are in use.  In
> looking at the system status, no tuners are in use.  With that said, I
> don't know if it is silently NOT recording anything that is scheduled
> because the tuners are all thought to be in use (is there a way to
> determine this?).
>
> The logs show:
> [..snip log data..]
>
> This seems to happen to all of the tuners, one by one..  A restart of
> mythbackend did not clear up this issue.  I ended up restarting the
> entire backend, and it started working again.
>
> Could this be an ivtv issue rather than a mythtv issue?
>
> -Rich

Just to follow up on my own posting, this looks to be an IVTV issue.  I 
am not sure if a fix is in the works, but I am running a rather recent 
kernel which is exhibiting this problem.

The actual logged error is:
2007-12-17 08:44:30.972 MPEGRec(/dev/video1) Error: select timeout - 
ivtv driver has stopped responding

So.. as a band-aid workaround, I set up a script to check the 
mythbackend log file every 5 minutes (out of cron) for that specific 
IVTV error.  If it is detected, the backend gets shut down, the ivtv 
driver gets unloaded from the kernel and loaded back in to the kernel 
again, and the backend gets started up again.  This (when done by hand) 
resolves the problem.

If anyone else is experiencing this problem, I can pass along the (very 
small) perl script.  I figured it would be a little much to post it to 
the list.  This isn't much more than a band-aid hack, but it does 
prevent the scenario where things start falling apart and remain 
unnoticed for hours (which results in a bunch of zero length videos 
within mythtv, which really freaks it out).

-Rich