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

[Craig Huff]

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