<br><br><div class="gmail_quote">On Dec 16, 2007 4:22 PM, John Drescher <<a href="mailto:drescherjm@gmail.com">drescherjm@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Dec 16, 2007 4:09 PM, Chris Isip <<a href="mailto:cmisipster@gmail.com">cmisipster@gmail.com</a>> wrote:<br>> In my effort to get rid of the ivtv buffers full errors in dmesg, I have
<br>> made a couple of conclusions. Running optimize_mythdb.pl and backing up the<br>> mythtv database will result in this error. Furthermore, backing up the<br>> myth database with mysqldump causes the server to be unresponsive for the
<br>> duration of the backup which means no playback possible on any frontends and<br>> no recording will start. The backend does not actually crash. It seems any<br>> playback or recording is "queued" and starts immediately after mysqldump
<br>> finnishes. Hence the missing 8 minutes at the beginning of my recordings at<br>> 1 AM. Just thought I'd let the list know, in case somebody else is having<br>> these problems.<br>><br><br></div></div>
Why not schedule this at 3:00AM or some other time that you know you<br>will not be recording? The other way around this is to have the<br>database on a second machine or even a different hard drive than the<br>controller. Both of these database operations are very hard drive and
<br>interrupt intensive (because they end up causing a lot of hard drive<br>thrashing) and the problem with that is that it ends up the you<br>filesystem is not able to keep up with the datarate that ivtv needs.<br><br>John
<br>_______________________________________________<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a></blockquote><div><br>I am actually testing a script right now that checks if there are any active recordings or playback as well as any active jobs that mythshutdown is able to monitor. If there are none, then do the backup. I time it to happen at 40 1,2,3,4,5 * * * in cron (five attempts in the wee hours of the morning, when there is no one using livetv). A successful backup is recorded and the script will not backup more than once in a 24 hour period. Since the backup lasts about 8 minutes or so, starting it at 40 minutes means it will finnish before the start of the next hour and so should't interfere with any future recordings. This is an offshoot of the mysql restart script I had to write because of a memory leak in mysqld. I have a similar script for optimize_mythdb.pl and it is set at 20 1,2,3,4,5 * * * in cron. Hopefully, between these, I would completely eliminate the ivtv errors as well as the dropped minutes in recording.
<br><br><br><br><br></div></div><br>