[mythtv-users] Problem with Myth Database

[Tom Dexter]

On 4/7/21, Craig Huff <huffcslists at gmail.com> wrote:
> I finally checked into why I was having job queue errors on recordings for
> commercial flagging operations.  I saw a lot of errors in mythbackend.log
> about the recordedseek table, so I manually ran optimize_mythdb and it
> reported:
> DBD::mysql::db do failed: Table './mythconverg/recordedseek' is marked as
> crashed and last (automatic?) repair failed at /usr/bin/optimize_mythdb
> line 38.
>
> I still have multiple gigabytes in / (root), /var, and the multiple /video*
> directories, FWIW.  I _do_ have a large backlog of videos to watch when
> time permits, so could it be that the table has gotten too big / full for
> mysql to handle?
>
> The .TMD file is 2.1G (2209087488),
> the  .MYD file is 2.1G (2209887450), and
> the  .MYI  file is 2.1G (2147819520).
>
> There's also a .BAK file from 2018 lingering around.  Not sure what that
> means, either.
>
> What do I do now?
>
> --
> Craig.
>

There's no way the size of the table is an issue. In my work I've
dealt with MySQL MyISAM tables in the TB range with as many as 7
billion rows.

A few things to note about what you have there:

The only files that are really used for a MySQL MyISAM table are the
.frm, the .MYD, and the .MYI. The only time you'd normally have a .TMD
file is in a case where MySQL was rebuilding the .MYD file...for
example if you were in the middle or doing a "REPAIR TABLE". That may
build a .TMD file and at the very end rename it to the .MYD table.

What's the time on that .TMD table? Depending on what distribution you
have, some will (like Debian I believe) may check for crashed tables
on startup and may automatically try to repair something. If the time
on that .TMD file is current, you may want to log into the mysql
command line and enter "show processlist;" to see if there might be a
repair running.

Oh...and I'd say that .BAK file is just cruft for sure.

Tom