I have the same issue but I think it happens to me when mysql corrupts a table 'recordedmarkup'. (causing the system to go nuts) I believe my corruption issue might be related to my northbridge fan going out and possibly causing the system to reboot mid stride from overheating or something. I just replaced it a few mins ago to figure out if this is whats causing it. But I guess there is always the possiblity that this error message is bogging down the system so much that it is the cuprit but thats not what i'm thinking right now.
All I know is this system used to stay up for months on end without any problems. Since I've moved away from 0.3.8 it has been flakey to say the least. But I think my problems is probably due to the problem stated above. I will wait and see I guess, if not I'm going to have to decide if mythtv cares if I switch them to InnoDb over MyISAM. I have little faith in MyISAM on large tables from past experience anyways so I'd really prefer the switch either way. But thats my next step before I decide that its ivytv. Anywho, that error message needs to be supressed somehow. Currently I'm waiting around for the hundreds of megs of that log to roll off from the last time it happened. -Mike Keith Pyle wrote: >With respect to the hang mentioned below, we've seen the same problem >with 0.4.0 rev. 2810 (of 10/12/2005) too. We see log messages like: > >Nov 15 09:08:52 myhost kernel: ivtv0 warning: Firmware UNRESPONSIVE when >trying cmd 0x000000cd!!! > >We are running with a SMP 2.6 kernel on a HT system. There were some >suggestions on this list that ivtv might not be SMP safe. To test this >theory, we disabled HT in the BIOS but left the SMP kernel and all other >parts of the system configuration unchanged. The system has been stable >for 20 days. Previously, it would have the firmware hang much more >frequently than this. > >Before ivtv was first installed, this system would stay up for hundreds >of days. > >While I would very much like to have HT enabled again, the system is at >least stable now. I'm reluctant to upgrade ivtv or any of the other >components given all of the problem reports recently. > >So, are you running SMP too? > >Keith > > > >>See this thread on the mythtv mailing list: >> >>http://www.gossamer-threads.com/lists/mythtv/dev/166787 >> >>I have noticed this, as well. This started when I upgraded to >>mythtv-svn-8042 (fetched 11/26/05) from mythtv-svn-7283 (fetched >>9/21/05). However, since the reason for the upgrade was improved DVB >>support in Mythtv, I also upgraded the kernel, and consequently IVTV from >>0.3.9 to 0.4.0. I believe that this may ultimately be found to be an issue >>w/ the live-tv changes in MythTV, though I can't verify this because I made >>the mistake of changing more than one variable at once :( >> >>I ended up editing ivtv-queue.c and just commenting these error >>messages, as they occur at such a rate that it will eventually eat up >>hundreds of megabytes of disk space (/var/log/syslog, /var/log/kern.log, >>/var/log/messages) before syslog even gets a chance to compress the logs >>and eventually swap them out. For this reason, I would like to suggest that >>the error message be suppressed after it is printed once every 10 seconds >>or something. >> >>However, w/ 0.4.0 it seems that the ivtv driver will eventually enter a >>non-funtional state: the device /dev/video0 will cease to respond. For >>instance, "cat /dev/video0 > /tmp/test.mpg" will never write any data to >>the file, and cat will hang (evidentally, cat is stuck closing >>/dev/video0). Likewise, Mythtv will print timeout messages in its log file, >>and I won't get my shows ;( >> >>Hope this info helps! >> >>Thanks, >>Andy >> >> >>Niels den Otter: >>|All, >>| >>|I'm using Mythtv SVN and I believe that my problem started since the >>|recent LiveTV changes. I'm not completely sure the problem is IVTV's or >>|Mythtv's, but since the ivtv driver logs error messages at the time the >>|problem exists, I first try to see if someone on this list can help me >>|to debug/solve the problem. >>| >>|When I watch LiveTV and a planned recording starts, the ivtv driver >>|starts spewing the following message continuously and the recording goes >>|wrong completely. >>| >>|Dec 10 17:38:29 localhost kernel: ivtv0 warning: ENC Stream 0 OVERFLOW >>|#303: Stealing a Buffer, 512 currently allocated >>| >>|Restarting mythbackend (and then also the frontend) stops this and >>|allows me to watch TV again. The recording then goes well also. >>| >>|I use a PVR-350 and have tried different ivtv versions (4.0 SVN and >>|current version is version 0.4.1 (development snapshot)), but without >>|luck. I use the following firmware: >>| >>|ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes) >>|ivtv0: loaded v4l-cx2341x-dec.fw firmware (262144 bytes) >>|ivtv0: Encoder revision: 0x02050032 >>|ivtv0: Decoder revision: 0x02020023 >>| >>|Googling for this problem I found the following suggestions of which >>|none helped: >>| * check available free memory >>| * check available free disk space >>| * load ivtv with ivtv_debug=0 and ivtv_dynbuf=1 >>| * ivtvctl -x 0 >>| >>|I have this problem for some time now and it is very inconvenient. All >>|suggestions for further debugging or to solve this problem are more than >>|welcome. >>| >>| >>|Thanks, >>| >>|Niels >>| >>| >> >> >> _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
