[mythtv-users] Software changes required when switching CPU from single-core to multi-core?

Raymond Wagner raymond at wagnerrp.com
Wed May 25 15:17:14 UTC 2011


On 5/25/2011 10:32, Craig Huff wrote:
>
> 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.
>

The problems with 0.24 were the result of unfortunate timing.  The V4L 
headers were removed from the source to rely on ones packaged by the 
distro.  At the same time, those V4L1 headers were removed from the 
2.6.38 kernel, and since MythTV is designed to fall back on the V4L1 
ioctls for support outdated drivers, lack of those drivers results in 
MythTV being built without analog support.  MythTV built on a prior 
kernel will function just fine.

> 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.
>

The 'fullness' of the hard drive isn't the issue, but rather the 
fullness results in fragmentation, which results in decreased 
performance, and eventually insufficient IO during recording.  This 
would result in blocky files, with missing chunks, rather than the whole 
thing disappearing.  Further, since your database is on an independent, 
unaffected disk, playback on the frontend would stall, but the frontend 
should be otherwise responsive.

If you have full recording drives, such that the auto-deleter has to run 
mid recording, and you're using ext3, and you don't have it set to use 
slow deletes, a delete of a several GB recording may deadlock the disk 
subsystem for extended duration, preventing recordings from being 
stored, and possibly from accessing the database on an independent 
disk.  I don't know if the ext3 issues are local to the disk in 
question, or affect the whole system.

If you are out of memory and heavily swapping, or otherwise doing an IO 
intensive operation on the system disk like compiling, or building the 
'locate' database, you could be causing too much IO and preventing 
access to the database.  Such activity would affect both recordings, and 
interactive access in the frontend.

> 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.)
>

I'm thinking of stuff like a damaged index.  Something that would allow 
the database to continue operation, but would severely limit its 
performance.  However the optimize_db.pl script should take care of 
rebuilding such issues.


More information about the mythtv-users mailing list