This script was inspired by a conversation with Marc Aronson about DB optimization to reduce buffer overflows/underflows caused by DB latency...

A more sophisticated approach would use the higher level mysql commands like "REPAIR TABLE", "ANALYZE TABLE", and "OPTIMIZE TABLE". On the other hand this is fairly simple and robust and should even work on DBs that have suffered some damage where having the mysqld daemon running may present problems. In an ideal world this might also stop the frontend to keep it from whining about the DB server being inaccessible or causing other mischief.

if [ "$1" = '-b' ] ; then # Optionally, make a backup before we start... # I'm not sure how useful this is, since both recover and analyze # are pretty safe operations... /usr/local/bin/mythbackup || fatal "Backup failed! Aborting!"fi# The database needs to be idle when we do this...# Having it auto restarted would also be "bad". ;-)/etc/init.d/mythtv-backend stop/etc/init.d/mysql stop

For those who are still experiencing IOBOUND errors and "Application not reading fast enough" problems, here are three more things to consider:

1. Reducing the number of days of program guide data that I kept in my database from the default of 14 to 9 also reduced the incidence of â€œIOBOUNDâ€? errors for me. Since you already have 14 days of program guide data in your database, it will take 5 days before you see the full benefit of this change. On R5D1: utilities/setup->setup->general->â€?mythfilldatabaseâ€? (screen # 7): Modify the field â€œmythfilldatabase argumentsâ€? to read â€œ--quiet --max-days 9â€?, without the quotes.

2. If you have any unused video sources hanging around, delete them using the myth-setup utility. This reduces the volume of data downloaded from zap2it into the database. Only do this if the video source is not needed and is not connected to any tuner cards:

3. There are a lot of â€œwatchdogâ€? scripts scattered around various sites that are designed to detect backend failures and execute an automatic restart. Some of these scripts include a call to the status port (6544) to see if the backend is still running. This can be a problem as a call to the status port will issue ~500 database queries. A better approach that works under R5D1 is to invoke the â€œsettingsâ€? screen, which only issues ~10 database queries:

Code:

â€¢ Look in your script for a command that reads something like â€œlynx -dump http://localhost:6544â€?â€¢ Replace that command with â€œlynx -dump http://localhost/mythweb/settingsâ€?â€¢ The script may grep an output file for a specific string such as â€œScheduleâ€?. If your script does this, replace the search string with the following: â€œThis is the index pageâ€?

Items 1 & 2 and the data base optimization reduces the I/O load every time the scheduler runs, which is quite frequent.

Re: start vs. restart - This was intentional "sanity preserving behavior". On a multiuser system it's generally not a good idea to assume that you know the state of given daemon, or that whoever wrote the start script provided enough protection against attempts to start twice. Using restart is cheap insurance.

Re: perl script. - Those are essentially the higher level commands I was talking about. On the other hand the way it hunts for the mysql.txt is a bit risky (a system might have multiple files and there's no guarantee that the first one it finds is the right one).

# Set the following if you want to use something other than the# machine's real hostname for identifying settings in the database.# This is useful if your hostname changes often, as otherwise# you'll need to reconfigure mythtv (or futz with the DB) every time.# TWO HOSTS MUST NOT USE THE SAME VALUE#LocalHostName=mythbox

# If you want your frontend to be able to wake your MySQL server# using WakeOnLan, have a look at the following settings:## Set the time the frontend waits (in seconds) between reconnect tries.# This should be the rough time your MySQL server needs for startup#WOLsqlReconnectWaitTime=0### This is the amount of retries to wake the MySQL server until the frontend# gives up#WOLsqlConnectRetry=5### This is the command executed to wake your MySQL server.#WOLsqlCommand=echo 'WOLsqlServerCommand not set'

A quick scan of the script will show that it has no protections against conflicts with scheduled events. I think this is probably better delegated to a utility wrapper script which takes an estimate of how big a time window is needed and the command to run, and then figures out if it's safe to start. I don't think the Perl script has any checking either, but it may "work" while the DB is running. (Much like mythfilldatabase does, potentially creating enough latency to cause buffer overruns.)

Yes, '~' is the character emacs and emacs like editors (in this case jed) use for the previous backup version of a file when you edit it. With a diff that simple it's an easy manual patch. For more complex changes you can feed a context diff like that to the patch utility and have it automatically reproduce the change.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum