<p>On May 25, 2011 7:44 AM, "Raymond Wagner" <<a href="mailto:raymond@wagnerrp.com">raymond@wagnerrp.com</a>> wrote:<br>
><br>
> MythTV runs multiple processes, and each of those processes has multiple<br>
> dozen threads, and among those threads there are multiple independent<br>
> pathways not locked under shared mutexes. What you may be thinking of<br>
> is software video decoding, which is limited to single threaded<br>
> operation by the decoding libraries, ffmpeg. Even that is not entirely<br>
> true, because multi-sliced h264 can be decoded in multiple threads, and<br>
> the decoding profiles default to two threads in this case. That is the<br>
> _only_ option pertaining to threading that you can control in MythTV<br>
><br>
> The Athlon 64 3200+ is a 2GHz socket 939 chip. The Athlon 64 X2 3800+<br>
> is a 2GHz dual core socket 939 chip. You do not have an Athlon II, as<br>
> that is a whole new architecture with a whole new incompatible socket.<br>
> Your new chip is exactly as fast as your old chip in single threaded<br>
> operations, and aside from some shared resources like memory and bus,<br>
> should have roughly double the performance on multi-threaded operations.<br>
><br>
> You are running an unstable version of MythTV on the 0.23-fixes branch,<br>
> several hundred revisions prior to stable release. This may very well<br>
> be causing a number of your problems. Other possibilities could be a<br>
> nearly full hard drive for either recording, or database storage, or a<br>
> damaged database that is causing excessively long queries when under<br>
> heavy recording load. It should be completely independent of your CPU<br>
> swap, which is likely to have just coincidentally happened at the same<br>
> time these problems started to appear.<br>
> </p>
<p>Wow! Thanks for the detailed reply. As for the Athlon II vs. 64, you are no doubt right. Serves me right for trying to go from memory.</p>
<p>Now, your reply raises new questions:<br>
1) How do I upgrade to a stable version, given that I'm using Mythbuntu; preferably 0.23.xxx, unless I have been misreading the list talk about 0.24 issues -- all my recordings are from a pair of PVR-500s as I only have Comcast DTAs as video sources.<br>
2) What, in this case, constitutes a nearly full HD? > 90%? > 80%? ...? Or is this one of those wonderful cases of "It depends" ;-) FWIW, the partitions boot, root, swap, and var are on an 80 GB IDE drive and videos are spread across (one each) 250GB, 500 GB, & 1 TB drives.<br>
3) DB damaged in some way that the optimize_DB perl script doesn't handle? (I run the script as part of the standard shutdown process that occurs when there will be a long time before the next recording event.)</p>
<p>TIA for any additional advice.<br>
Craig.</p>