Revision as of 22:26, 9 January 2008

It is possible to corrupt your seektable for one or more recordings, which can result in:

• Being unable to skip forward and backward correctly, and
• Recordings reporting the incorrect length.

mythcommflag and mythtranscode are two tools that can be used to rebuild the seektable.

Note: After rebuilding the seektable, any cutlist you have created for a recording will no longer be properly synced and should be recreated.

Repairing the Seektable

Preparation

First, run the optimize_mythdb.pl script to ensure that the MySQL database is in good order.

For my Ubuntu Feisty machine, this is as simple as running the following command:

sudo /usr/share/doc/mythtv-backend/contrib/optimize_mythdb.pl

This will iterate through each of the tables in the mythconverg database, 'optimizing' each one. Once the optimize_mythdb.pl script has returned successfully, it is time to move on.

Using mythcommflag

mythcommflag is generally very successful and very efficient at rebuilding the seektable.

For each recording that you wish to repair, run the following command:

mythcommflag --file <filepath> --rebuild

where <filepath> is the path to a recording that exists in the Myth TV database. There are other options that can be used to specify the input filename(s), refer to the mythcommflag page for further details.

Note: mythcommflag should always be used for files that are recording in or transcoded to NUV.

Using mythtranscode

If you have trouble rebuilding a seektable with mythcommflag, try using mythtranscode as follows:

mythtranscode --mpeg2 --buildindex --showprogress --infile <filepath> 

where <filepath> is the path to a recording that exists in the Myth TV database. There are other options that can be used to specify the input filename, refer to the mythtranscode page for further details.

It should be noted that mythtranscode generally does a better job at repairing MPEG-TS (and/or MPEG-PS) streams.

Possible Causes of a Corrupt Seektable

• Editing a recording outside of the MythTV Frontend.
• Excessive disk IO during recording could prevent invalid SQL updates to the recordedseek table (I think).
• Crashed MySQL tables.
• Losing the network between slave backends and the MySQL database server during recordings.