[mythtv-users] Recordings slow to start?

[Stephen Worthington]

On Wed, 1 Jul 2015 20:50:39 -0500, you wrote:

>Ever since I upgraded to a 2TB HD and expanded my 2 tuner HDHR-ATSC to
>include a 3 tuner HDHR-Prime I've noticed that my recordings take a long
>time to start, up to 10 seconds.
>
>Since it can't take that long to find a file my assumption is that it's
>loading the recordseek table that's taking so long.
>
>I occasionally use the Optimize button in mythweb and recently tried the
>optimize_mythdb perl script but it doesn't seem to have helped.
>
>I also occasionally run mysqld_tuner and apply the recommendations.
>
>Anywhere else I should look?
>
>Thanks,
>Richard

There is an updated version of optimize_mythdb.pl from 25-Jun-2015. If
you are using Mythbuntu and relying on the version it runs as a cron
job, you will not be using the updated version yet.  The cron job is
here:

  /etc/cron.daily/optimize_mythdb

and if you are getting the Mythbuntu fixes, the new version is here:

  /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl

You can just copy the new version over the old one to update it.  It
is only the new version that has these added bits that help with the
problem of huge recordedseek tables:

# Defragement seek table
    if ($dbh->do("ALTER TABLE `recordedseek` ORDER BY chanid,
starttime, type")) {
        print "Defragmented: recordedseek\n";
    }
# Defragement program table
    if ($dbh->do("ALTER TABLE `program` ORDER BY starttime, chanid"))
{
        print "Defragmented: program\n";
    }
# Defragement video seek table
    if ($dbh->do("ALTER TABLE `filemarkup` ORDER BY filename")) {
        print "Defragmented: filemarkup\n";
    }

It certainly seems to have helped with my slow startup when playing
recordings.  Be aware that it takes quite a while to order the
recordedseek table when it is huge.  Mine is massive:

mysql> select count(*) from recordedseek;
+----------+
| count(*) |
+----------+
| 95040874 |
+----------+
1 row in set (0.01 sec)

and it takes about 20 minutes to process it.  The database is still
usable while it happens though.  But the whole optimise_mythdb script
does create quite an I/O and disk load while it is running, so it is
best scheduled for when MythTV (and anything else on the box) is not
busy.  It potentially could cause sufficient load to make recordings
fail if the box is busy enough.