<br><br><div><span class="gmail_quote">On 2/13/07, <b class="gmail_sendername"><a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu</a></b> <<a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Where exactly is your database?<br><br>As a PVR-x50 user who's been getting screwed for a year by glitches
<br>caused by MySQL locking winding up locking out other table accesses,<br>this is a sore spot.<br><br>I'm assuming that the HDHR isn't trying to write into recordedmarkup<br>or its SVN incarnation (unlike the ivtv-based encoders), but I'm
<br>wondering if perhaps there's something wrong with your database<br>(like crashed or extremely un-optimized tables) that's either causing<br>outright disk contention, or lots of swapping that is itself screwing
<br>your ability to write to disk. So you might try repairing and<br>optimizing tables (if you don't already) and see if that helps.<br><br>And of course the FE makes large transient demands on the database,<br>hence my suspicion. Is your DB on the master backend's CPU? Same
<br>disk, or a different disk? (In -my- case, of course, it made no<br>difference, since it was the DB locking itself that was a problem and<br>not contention for disk bandwidth, but this wasn't obvious for most of<br>
a year.) Is your backend swapping a lot? Can you try moving your<br>database to a completely different machine to run a test?<br><br>(You can accomplish this latter, essentially, by shutting down MySQL,<br>copying its files to some other machine -with a compatible version-
<br>installed [don't recklessly switch MySQL versions if you're just<br>copying raw database files w/o import/export!], and changing the<br>config file on your backend to point to whichever host now has the DB.)<br>
<br>P.S. If your test system is using the MySQL server on your production<br>backend, of course, you're splitting things off in a way that might<br>cause the test system to work fine while the production machine is<br>
encountering contention issues...</blockquote><div><br>Thanks for the suggestion concerning the database. Another thing I had not thought of. My installation of myth is right from the ATrpms packages, so wherever the database is installed by default is where mine is located. It's definitely on the same system (CPU) as the B/E. On the test system I did not point it to the database on the B/E; this was a fresh install of Myth, just taking the defaults.
<br><br>A couple of questions for clarification purposes:<br>You say shutdown MySql and copy it's files to another machine. Are you referring to just the database files, or do I also need to copy over my actual recordings? Also, since the other machine won't have the tuner cards in it, how will myth react to having these cards, and all associated info, in the database, but not being able to physically access them? Will this cause any issues?
<br><br>You also say that the FE makes large transient demands on the database. Are you referring to a remote FE system, or just the FE functions (LiveTV, Watch Recordings, Schedule Recordings, etc.) in general? Because when I do these functions directly on the BE machine I don't get any corruption; at least that has been what I have seen so far. This is one of the things that really has me confused. It's only when I connect up to the BE with a FE running on another machine that I have problems.
<br><br>Thanks again,<br>John<br><br><br> <br></div><br></div><br>