[mythtv-users] Help needed with error in recordedseek table not fixed by optimize_mythdb

[Mark Perkins]

On 29 January 2018 8:41:13 am Craig Huff <huffcslists at gmail.com> wrote:

> On Sun, Jan 28, 2018 at 3:31 PM, Craig Huff <huffcslists at gmail.com> wrote:
>
>> On Sun, Jan 28, 2018 at 3:14 PM, Craig Huff <huffcslists at gmail.com> wrote:
>>
>>> On Sun, Jan 28, 2018 at 3:03 PM, John Pilkington <J.Pilk at tesco.net>
>>> wrote:
>>>
>>>> Restore from earlier backup?
>>>>
>>>>
>>> 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.
>>>
>>> For lurkers/future searches of the mailing list, the mail link I found
>>> was http://lists.mythtv.org/pipermail/mythtv-users/2014-February
>>> /360413.html
>>>
>>> As I _do_ have backups of the database, I can do as you suggested, but
>>> I'd like to try this first.
>>>
>>> --
>>> Craig.
>>>
>>
>> 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?
>>
>> 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).
>>
>> --
>> Craig.
>>
>
> 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.
>
> 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.
>
> I could use more advice.
>
> --
> Craig.
>
>
>

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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20180128/eb36f424/attachment.html>