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

[Craig Huff]

On Wed, May 25, 2011 at 10:17 AM, Raymond Wagner <raymond at wagnerrp.com> wrote:
> 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.

Okay... How do I update mythtv, and I presume that should be _all_ of
mythtv?  And is there something I can (probably _should have_) set to
get it updated automatically?

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

More info first, FWIW:
/video, /video2, and /video3 are all formatted as full-disk partitions
with JFS.  Sizes, Use %ages, and GB Avail are:
500G  250G  1000G
97%   85%    72%
18G   38G     263G

Also, and probably more telling, just got home and discovered that it
did it again last night, so I started trolling the various log files.
mythbackend.log reported these selected lines:
2011-05-24 21:59:31.827 RecBase(3:/dev/video2):
GetKeyframePositions(676,9223372036854775807,#7) out of 53
2011-05-24 22:00:35.345 DevRdB(/dev/video2) Error: Poll giving up
2011-05-24 22:00:35.347 MPEGRec(/dev/video2) Error: Device error detected
2011-05-24 22:00:35.347 DevRdB(/dev/video2): Stop(): Not running.
2011-05-24 22:00:38.411 DevRdB(/dev/video2) Error: Poll giving up
2011-05-24 22:00:38.413 MPEGRec(/dev/video2) Error: Device error detected
2011-05-24 22:00:38.413 DevRdB(/dev/video2): Stop(): Not running.

Then found these lines (and many more similar) in syslog:
May 24 22:00:33 MythBE kernel: [43667.496771] ivtv2: DMA TIMEOUT 00000001 0
May 24 22:00:33 MythBE kernel: [43667.825025] ivtv2: DMA TIMEOUT 00000001 2
May 24 22:00:33 MythBE kernel: [43668.156908] ivtv2: DMA TIMEOUT 00000001 2
May 24 22:00:36 MythBE kernel: [43670.593024] ivtv2: DMA TIMEOUT 00000001 2
May 24 22:00:36 MythBE kernel: [43670.893032] ivtv2: DMA TIMEOUT 00000001 0
May 24 22:00:36 MythBE kernel: [43671.192028] ivtv2: DMA TIMEOUT 00000001 2
May 24 22:00:37 MythBE kernel: [43671.493024] ivtv2: DMA TIMEOUT 00000001 2

And a clarification:
My FE is set up in the living room with old-tech 27" CRT TV, so no
keyboard or mouse, just frontpanel controls and IR remote, so when
mythfrontend is stuck trying to contact the database and/or
mythbackend on the BE, (which is upstairs BTW) I'm kinda limited to
being patient or use the metaphorical sledgehammer.  Well, ok, I
_could_ go upstairs and remote log in the the FE and do things, but
ATM, I'm recuperating from abdominal surgery and supposed to avoid
unnecessary trips up and down ;-)

So new questions:
A) Any better way to defrag (for future reference, at least) than our
old trick _and_ painfully slow of dump entire FS somewhere else,
delete -R /video{|2|3}/*.*, and then restore from "somewhere else", be
that another disk or tape?
B) How do I get to the bottom of the occasionalness of this DMA
timeout problem and fix it?

N.B.: While working on this e-mail, I found I didn't have
smartmontools installed, so I did that and have it running.  Ran
smartctl -a -d ata /dev/sdb and got way more than I could digest, but
it _did_ say something to the effect "disk a-ok".

Again, thanks for sharing your wisdom.
Craig.