<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 28, 2018 at 5:30 PM, Mark Perkins <span dir="ltr"><<a href="mailto:perkins1724@hotmail.com" target="_blank">perkins1724@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="color:black"><div><div class="h5">
<p style="margin:0 0 1em 0;color:black;font-family:sans-serif">On 29 January 2018 8:41:13 am Craig Huff <<a href="mailto:huffcslists@gmail.com" target="_blank">huffcslists@gmail.com</a>> wrote:</p>
<p style="margin:0 0 1em 0;color:black;font-family:sans-serif">> On Sun, Jan 28, 2018 at 3:31 PM, Craig Huff <<a href="mailto:huffcslists@gmail.com" target="_blank">huffcslists@gmail.com</a>> wrote:<br>
><br>
>> On Sun, Jan 28, 2018 at 3:14 PM, Craig Huff <<a href="mailto:huffcslists@gmail.com" target="_blank">huffcslists@gmail.com</a>> wrote:<br>
>><br>
>>> On Sun, Jan 28, 2018 at 3:03 PM, John Pilkington <<a href="mailto:J.Pilk@tesco.net" target="_blank">J.Pilk@tesco.net</a>><br>
>>> wrote:<br>
>>><br>
>>>> Restore from earlier backup?<br>
>>>><br>
>>>><br>
>>> I found an earlier message on the mailing list by Michael Dean from last<br>
>>> February that pointed to a web link for myisam table maintenance. The<br>
>>> simple table check reported the same table with the same symptom, along<br>
>>> with one named #sql-5de_e6a.MYI as corrupted. I suspect the latter file is<br>
>>> a mysql internal table and do not plan to touch it. As for the<br>
>>> recordedseek table, the next step is to use myisamchk to attempt a repair<br>
>>> on it using the "easy safe repair" step.<br>
>>><br>
>>> For lurkers/future searches of the mailing list, the mail link I found<br>
>>> was <a href="http://lists.mythtv.org/pipermail/mythtv-users/2014-February" target="_blank">http://lists.mythtv.org/<wbr>pipermail/mythtv-users/2014-<wbr>February</a><br>
>>> /360413.html<br>
>>><br>
>>> As I _do_ have backups of the database, I can do as you suggested, but<br>
>>> I'd like to try this first.<br>
>>><br>
>>> --<br>
>>> Craig.<br>
>>><br>
>><br>
>> Hmmm... The "easy safe repair" step looked like it worked as seemingly<br>
>> confirmed by re-running the myisamchk test against the recordedseek.MYI<br>
>> file afterwards, but once I restarted mysql and mythtv-backend and tried<br>
>> running optimize_mythdb again, I get the same error result and a subsequent<br>
>> run of myisamchk shows the error is back again. Maybe I need to fix the<br>
>> #sql-5de_e6a.MYI file, too?<br>
>><br>
>> Not so sure I'm comfortable with that. I'll ponder on that awhile, whilst<br>
>> hoping someone can chime in with more advice, since my last db backup was<br>
>> done before the most recent recordings (backup was Saturday morning so<br>
>> recordings done in the last 24 hours would be unaccounted for).<br>
>><br>
>> --<br>
>> Craig.<br>
>><br>
><br>
> Well.... The recordedseek table keeps coming back bad, even though<br>
> myisamchk (using only the "easy safe repair" step) seems to indicate it<br>
> fixed the table.<br>
><br>
> I could restore the tables from my last backup to an alternate location and<br>
> overwrite the recordedseek.* files with those from the backup and then run<br>
> jobs to build the seek data for the recordings done since that backup, but<br>
> I'm not sure if that would introduce corruption with recordedseek data not<br>
> being in sync with other tables.<br>
><br>
> I could use more advice.<br>
><br>
> --<br>
> Craig.<br>
><br>
><br>
><br>
</p>
</div></div><p style="margin:0 0 1em 0;color:black"><br>
I am intrigued as to why that table keeps repeatedly crashing. Have you checked for sufficient disk space / inodes / mysql temp space? It can be a very big table and it might need a lot of temp space for the operations.
</p>
<p style="margin:0 0 1em 0;color:black">Also are you using the optomise script suitable for your version of mythtv? I thought that the defrag was only added recently, at least after fixes/0.27 (cannot immediately see that that would be the issue but stranger
things have happened). </p>
</div>
</div>
<br></blockquote></div><br>Mark-<br><br></div><div class="gmail_extra">Thank you for your input.<br><br></div><div class="gmail_extra">I goofed up and rebooted my system at an inopportune time this morning when I should have looked to see what it was doing. It was in the midst of running optimize_mythdb and of course, it was working on the single biggest table in the database, namely recordedseek.<br><br></div><div class="gmail_extra">I believe that myisamchk is only fixing the index records (*.MYI) and there are corresponding anomalies in the actual data file as well (*.MYD).<br><br></div><div class="gmail_extra">I am using the correct version of optimize_mythdb, but thanks for making me check.<br><br></div><div class="gmail_extra">I'm not sure where the comment about defrag is coming, but I don't think that's relevant in my current circumstance.<br><br>--<br></div><div class="gmail_extra">Craig.<br></div></div>