[mythtv-users] Issues with 0.25

Gavin Hurlbut gjhurlbu at gmail.com
Tue Mar 6 18:15:30 UTC 2012


On Tue, Mar 6, 2012 at 7:02 AM, Scott and Nicole Harris
<snharris99 at live.com> wrote:
> itself is an issue]).  The part that seems to be being overlooked here, is
> that users experiencing these bad recordings in 0.25 can remedy the
> situation by rolling back to 0.24 (myself included), suggesting that the
> issue is in 0.25, not hardware or corrupt data.  The issue only seems to
> affect HDHR users and only when performing more than one recording at a time
> (as near as I can tell by the "me too's" in this thread).

If the database is not corrupt, then I'd suggest using mysqltuner.pl
and see if there isn't something you need to tweak in my.cnf.

The one huge difference between 0.24 and 0.25 is that in 0.25 we log
to the database by default.  This adds a non-insignificant additional
load to mysql, but if it is setup properly, there's no reason it
should cause alarm.  To see if that's the problem, start the frontend
and backend with --nodblog and see if it changed.

> Other than max_connections being set to suitably (much higher) amount, what
> other specific settings should we be looking at?

Sizes of caches and the like, primarily.

wget mysqltuner.pl

> Perhaps the total revamping of the MySQL thread pool that now requires such
> a large increase in max_connections is contributing to the high CPU usage
> with multiple recordings?

Doubtful.  I often have 6 recordings at once, additional to a MythTV
compile and 4 flat out commflag runs, and I don't see any issues.  And
my database is on ext4 with barriers enabled.  Granted, I'm using an
i7-860, so I have 4 hyperthreaded cores (so 8 CPUs as seen by Linux).

> Is using xfs for recording drives over ex4 a potential issue?

Not likely.


More information about the mythtv-users mailing list