[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