[mythtv] "ivtv driver has stopped responding"

[Derek Battams]

Quoting George Nassas <gnassas at mac.com>:

> On 8-Feb-06, at 2:22 AM, Derek Battams wrote:
>
>> Running SVN 8881 and this is the second time in the last week or so
>> I've seen this  error.  An in-progress recording stops and my log fills
>> with:
>>
>> select timeout - ivtv driver has stopped responding
>>
>> until the show being recorded is scheduled to end.  Recordings on my
>> second tuner (also a PVR250) continue to work fine.
>
> I'm seeing this too and I'm also running a recent svn (8906). For me
> it's consistent on all recordings.
>
> After a day of looking into it the best I can tell is for some cases
> myth isn't connecting the ivtv encoder to a ring buffer. I posted a
> note about this - check the dev archives for the subject "null tvchain
> in TVRec::TuningNewRecorder". So far I haven't figured out a fix and my
> post hasn't drawn any guidance.

It sounds like your recordings don't ever start, is that correct?  For 
me, recordings start, but in the middle of the recording it stops and 
then my log fills with the 'select timeout' error until the scheduled 
end of the recording.  It's happened twice in the last week.  The first 
time was 35 minutes into a 3h45m recording and the second time was 
2h36m into a 3 hour recording.  Yes, I missed the end of the hockey 
game, though it was 5-2 at the time so the result was not in doubt. ;-)

Whatever was recorded up until the error is saved and I can watch the 
partial recording.  The error is produced by the select() call on line 
475 of libs/libmythtv/mpegrecorder.cpp returning 0, which signals a 
timeout.  I'm not sure if the readfd file descriptor is being changed 
else where in another thread or something (seems unlikely) or if the 
PVR card has indeed stopped sending data to the /dev/video0 device 
(also seems unlikely, but more likely than the former).  The tuner is 
immediately usable afterwards either to watch live tv or record 
something else so it doesn't appear that the PVR card is dying and the 
second tuner records fine even during this error on the first.  Either 
way, my attempt at a fix is to close the file and set the file 
descriptor to -1, which should force a reopen of the device on the next 
interation of the loop.  Currently, there's just a continue statement 
when this condition occurs.  Unfortunately, the issue has not reoccured 
since I've rebuilt with my attempted fix, so I'm still waiting to see 
what happens.

Along with my local patch, I also upgraded to SVN 8906, which may or 
may not make a difference.

  - Derek