Oh dear, I'm responding to myself here. I've spent 10 days looking into this and was about to give up, however all is now well.<br />
<br />
It turns out there was a submission that caused a possible infinite loop in the code. My machine hunted it down and executed that loop. Anyway, there's a possible fix for it too:<br />
<br />
http://svn.mythtv.org/trac/changeset/19357<br />
<br />
I haven't tested this because I'm a coward and stick to rpms - I've just reverted to an older version of libmyth, in fact 0.21-14.fc10:<br />
<br />
http://download1.rpmfusion.org/free/fedora/updates/10/x86_64/repoview/libmyth.html<br />
<br />
So now all is sweetness and light - it's been recording TV for an hour where previously it only got about 5 seconds.<br />
<br />
I'll get my coat.<br />
<br />
David<br />
<br />
"- David Bowen" <David@MyForest.Com> wrote:<br />
<blockquote type="cite">My story sounds very similar to Ian's. I'm still looking into the problem, but here's where I've got to so far:<br />
<br />
http://pastebin.com/m72a75fbc<br />
<br />
I've been using Myth for about four years and my setup has been stable for some time. We recently had a power cut and my box re-booted. When it came back up a number of recent updates came into effect. Chaos ensued as we were unable to use the mouse or keyboard due to fun with X - however we got that sorted.<br />
<br />
Unfortunately our server now hangs when we try to watch or record TV.<br />
<br />
I have tried the following in vain:<br />
<br />
* Reverting to an older myth<br />
* Reverting to an older kernel<br />
* Reverting the database to one from a few weeks ago<br />
* Creating a new database<br />
* Changing USB DVB sticks<br />
* Moving the recordings folder around (notably so it was not over NFS at one point)<br />
* Truncating the recordings folder<br />
* A myriad of other things that normally get me rolling<br />
<br />
To me (a non-C++ programmer) it looks like a one or more of the threads is getting stuck. Much of the functionality of the backend works, but the TV reception hangs up. The mythfrontend response is similar on a number of client machines. When it locks up the mythbackend process uses a whole core on my dual core box.<br />
<br />
So I eventually bit the bullet and got familiar enough with gdb / kdbg to look into the problem. On every occassion I ran it the failure was very similar. I can get it to fail quite reliably (which is nice).<br />
<br />
There always lots of threads, many just look like they are in some sort of wait state, but three always look interesting. One is in MPEGStreamData::IsEncryptionTestPID (thread 24 below). The other two are in ThreadedFileWriter::SyncLoop (threads 21 and 22 below). In this trace one of them is in DiskLoop however. When I look at the file on those two threads it's the same recording file.<br />
<br />
Note that I have my DVB card set to "Use unencrypted channels only".<br />
<br />
So a wild speculation would be that either the MPEGStreamData-related thread is locking with something else I don't see easily, or that the two file threads are stuck with each other or some combintation involving all three! The fact that my CPU goes to 100% suggest to me that it's not a deadlock int he sense that I see them in my database code I do at work for example.<br />
<br />
Attached is some gdb output (mixed in with mythbackend output as always). There's a slew of version information after that. The "Failed to open demux device" message has been in my logs for as long as I can remember and never seems to cause any harm. <hr />
_______________________________________________<br />
mythtv-users mailing list<br />
mythtv-users@mythtv.org<br />
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users<br />
</blockquote>