<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div style="color: black;">
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">On 29 January 2018 8:41:13 am Craig Huff <huffcslists@gmail.com> 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 <huffcslists@gmail.com> wrote:<br>
><br>
>> On Sun, Jan 28, 2018 at 3:14 PM, Craig Huff <huffcslists@gmail.com> wrote:<br>
>><br>
>>> On Sun, Jan 28, 2018 at 3:03 PM, John Pilkington <J.Pilk@tesco.net><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">http://lists.mythtv.org/pipermail/mythtv-users/2014-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>
<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>
</body>
</html>