[mythtv-users] ensuring mythbackend will be idle for db optimize

[Stephen Worthington]

On Mon, 21 Sep 2015 12:48:42 -0600, you wrote:

>I've used optimize_mythdb.pl regularly for a long time without much regard for the database being busy, because it never did more than check the DB and fortunately never found anything to repair, so it was pretty much a read-only operation.
>
>But the latest version in 0.27.5 will defragment seektables and that means writing the DB for sure.
>
>How will this behave while recordings are being made, processed, or watched?
>
>Will MySQL just handle the table-locking automagically? I suspect not.
>
>So, I think I need to find or write something that asks if the front- and backend is or will be quiet for the next N minutes, before optimizing. 
>
>Has anyone done this already? Creative uses of MythWelcome?

So far, it seems to be fine running an optimise or database backup at
the same time as recording.  I have been doing that for a couple of
months now.  My database is huge (13061 recordings), and it takes
quite a while to defragment the recordedseek table, but I have not
seen any problems from that if I have a recording in progress at the
same time.  Several times a week, I have one or more recordings in
progress when the optimise happens.

The only problem I have is not with MythTV, but with the decryption
software I use with my satellite card, which seems to have a bug that
makes it sensitive to too much I/O of certain sorts happening at the
same time.  Recordings that only use MythTV without the decryption are
fine, those with decryption can have gaps in the recording due to too
much I/O traffic when the database is being optimised, or if I have
too many decryptions happening at the same time.

The easy solution to this would likely be to have an SSD for my
database, but I am out of SATA ports to put one on.  So I am also
considering changing my /etc/cron.daily/optimize_mythdb script to
avoid times when recording is happening.  I already have a crude way
of doing this in my balance_storage.sh script, by parsing the output
of the mythtv-status command, so that balance_storage.sh will stop if
the next recording is within 5 minutes (or if there is a recording in
progress).  Feel free to borrow any code you like from it:

  http://www.jsw.gen.nz/mythtv/balance_storage.sh

So I could just do the same, and have the optimise script wait 15
minutes whenever it sees a recording running or scheduled in less than
15 minutes.  That should work, but there is likely now a much better
way of getting the time of the next recording directly from
mythbackend using the Services API or Python bindings.  When I find
the time, I intend to start learning about the Services API, which
seems to be where the new work is going now.