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

[John Pilkington]

On 28/01/18 23:30, Mark Perkins wrote:
> 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).
> 

When the seektable defrag was added there was a suggestion that it 
should perhaps be used less frequently.  I used to have versions; with 
and without, but that has lapsed.

I do have timers for each table.  Many take much less than a second, but 
recordedseek took 63 seconds to check and 95 seconds to defrag today.