> /var/log/mythtv/mythbackend.log contains a cycling of these messages: > > ... > 2008-02-16 15:59:32.445 MPEGRec(/dev/video0) Error: select timeout - > ivtv driver has stopped responding > 2008-02-16 15:59:38.052 MPEGRec(/dev/video0) Error: select timeout - > ivtv driver has stopped responding > ...
In my Nov 2007 version of MythTV, that timeout is 5 seconds. Every time you see that message MythTV has waited for 5 seconds for the cx18 driver to report it has data ready to read. There's a driver/kernel problem. The logic in the driver to support select() by the kernel is implemented in: cx18-fileops.c: cx18_v4l2_enc_poll() > dmesg contains a large number of these messages: > > cx18-0 file: Encoder poll started capture > cx18-0 file: open encoder MPEG > cx18-0 file: Encoder poll started capture > cx18-0 file: open encoder MPEG When MythTV times out on the select(), it closes the fd opened on /dev/videoN and reopens it on the next attempt to get video data. These messages reflect that behavior of MythTV and of the cx18 driver allowing select() to restart a capture in cx18-fileops.c:cx18_v4l2_enc_poll() The big question is why does the select() on a cx18 device node when video data should be there? I guess I'm going to have to start debugging the IRQ and DMA to see when/why the data stops flowing from the encoder chip. I still get the occasional select() timeout and freeze, but it has been usually resolving itself. > Fedora 8, single Pentium 4, 2.6G, 2G RAM, cx18 data: I have dual core: $ grep Core /proc/cpuinfo model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ so that might make some difference in our results. -Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
