<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 28, 2018 at 3:31 PM, Craig Huff <span dir="ltr"><<a href="mailto:huffcslists@gmail.com" target="_blank">huffcslists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="gmail-h5"><div class="gmail_quote">On Sun, Jan 28, 2018 at 3:14 PM, Craig Huff <span dir="ltr"><<a href="mailto:huffcslists@gmail.com" target="_blank">huffcslists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 28, 2018 at 3:03 PM, John Pilkington <span dir="ltr"><<a href="mailto:J.Pilk@tesco.net" target="_blank">J.Pilk@tesco.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Restore from earlier backup?<br>
<br></blockquote></div><br></div><div class="gmail_extra">I found an earlier message on the mailing list by Michael Dean from last February that pointed to a web link for myisam table maintenance. The simple table check reported the same table with the same symptom, along with one named #sql-5de_e6a.MYI as corrupted.  I suspect the latter file is a mysql internal table and do not plan to touch it.  As for the recordedseek table, the next step is to use myisamchk to attempt a repair on it using the "easy safe repair" step.<br><br></div><div class="gmail_extra">For lurkers/future searches of the mailing list, the mail link I found was <a href="http://lists.mythtv.org/pipermail/mythtv-users/2014-February/360413.html" target="_blank">http://lists.mythtv.org/piperm<wbr>ail/mythtv-users/2014-February<wbr>/360413.html</a><br><br></div><div class="gmail_extra">As I _do_ have backups of the database, I can do as you suggested, but I'd like to try this first.<br></div><div class="gmail_extra"><br>--<br></div><div class="gmail_extra">Craig.<br></div></div>
</blockquote></div><br></div></div>Hmmm...  The "easy safe repair" step looked like it worked as seemingly 
confirmed by re-running the myisamchk test against the recordedseek.MYI 
file afterwards, but once I restarted mysql and mythtv-backend and tried
 running optimize_mythdb again, I get the same error result and a 
subsequent run of myisamchk shows the error is back again.  Maybe I need
 to fix the #sql-5de_e6a.MYI file, too?<br><br>Not so sure I'm comfortable 
with that.  I'll ponder on that awhile, whilst hoping someone can chime 
in with more advice, since my last db backup was done before the most 
recent recordings (backup was Saturday morning so recordings done in the
 last 24 hours would be unaccounted for).<br><br>--<br></div><div class="gmail_extra">Craig.<br></div></div>
</blockquote></div><br><div><div><div>Well....  The recordedseek table keeps coming back bad, 
even though myisamchk (using only the "easy safe repair" step) seems to 
indicate it fixed the table.<br><br></div>I could restore the tables 
from my last backup to an alternate location and overwrite the 
recordedseek.* files with those from the backup and then run jobs to 
build the seek data for the recordings done since that backup, but I'm 
not sure if that would introduce corruption with recordedseek data not 
being in sync with other tables.<br><br></div>I could use more advice.<br><br>--<br></div>Craig.</div></div>