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.