[mythtv-users] Must mythbackend be running when executing optimize_mythdb.pl and/or mythlink.pl?

Michael T. Dean mtdean at thirdcontact.com
Fri Apr 6 15:05:16 UTC 2012


On 04/06/2012 07:44 AM, Craig Huff wrote:
> I currently run these scripts as part of my shutdown process on the
> backend, along with other things.  It seems I'm taking too long
> shutting down and sometimes mythbackend gets impatient and tries to
> restart things, occasionally ending up in a deadlock instead of
> actually shutting down.  In an attempt to fix this, I'm wondering if I
> can move execution of either (or both) of these scripts to run after
> mythbackend is killed in the shutdown process sequence.  Can anyone
> advise me on this?

mythlink.pl can definitely be run when mythbackend is running without 
having any effect on the backend or recordings or frontend or playback 
or ... (assuming your backend host/MySQL server is not severely 
underpowered).  (Before the support for use in MythTV System Events/user 
jobs,) I used to run it at 2 and 32 minutes after the hour, every hour, 
every day (but I almost never use the renamed links, now, so I only run 
it once per day), and never had any problems.

optimize_mythdb.pl can be run while mythbackend is running, but--as 
you've noticed--may take a while to complete.  While it's running, it 
locks tables, preventing other processes (such as mythbackend) from 
reading or writing those tables.  Therefore, running it when MythTV 
needs access to the data in the database may cause issues (including 
loss of some data for the new recording(s)).  So, we highly recommend 
that you run the script at some time when it's extremely unlikely that 
you'll be doing a recording.  I run it in a daily cron job that occurs 
at 4:38am.

Also, the only reason we don't automatically run optimize_mythdb.pl type 
functionality (repair/analyze/optimize)--we already have code in MythTV 
to do it all--is because if it were being run and the MySQL server 
crashes (mysqld crash/power outage/full file system/...) during a table 
repair, it's critical that a repair is run, again, after restarting the 
server and before any client attempts to read any data from the table 
that was being repaired--otherwise, you could lose all of the data in 
the table.  Therefore, since we can't guarantee that we'll be able to 
run the repair before anyone else reads from the table before, and 
because even doing a quick check to see if tables are good before 
starting the master backend slowed startup sufficiently, on some 
systems, that we had to remove the check.  That means 
repair/analyze/optimize are left to the user/"db admin" for the system.  
And, if there's a database crash, you should probably shut down all 
MythTV applications, then do an optimize_mythdb.pl or mysqlcheck -r 
before restarting MythTV (really, that's a good idea any time there's a 
MySQL crash, even if you weren't running a repair at the time).  
(Unfortunately, currently optmize_mythdb.pl requires a working settings 
table, so if your settings table is crashed, you'll need to run 
mysqlcheck -r directly--and figure out all the right command-line 
arguments.  I'm hoping to fix that, sometime.)

Mike


More information about the mythtv-users mailing list