[mythtv-users] Running optimize_mythdb.pl before mythfilldatabase

[Yeechang Lee]

David Brodbeck <gull at gull.us> says:
> Understood.  I don't think I've ever seen a corrupt MySQL table, but
> I'm sure it happens.

I don't know if the operative word is "corrupt" or "destroy"--more
accurately "corrupt, then destroyed by optimize_mythdb.pl," I
suppose--but twice in the past couple of months I've seen, after
forced reboots (involving what I describe at
<URL:http://www.gossamer-threads.com/lists/mythtv/users/242065#242065>),
the seektables for the previous week or two of recordings
destroyed. The damage isn't always obvious at first glance as the
end-recording time is usually (not always) correct. However, if one
tries to jump to near the end (say, 1:28:00 in a 1:28:37 recording),
then jump back to the start (from, say, 1:28:07), the OSD will only
jump back to 1:28:00.

It's a pain to rebuild the seektables manually,[1] but otherwise the
database is completely intact in such cases as far as I can tell.[2]

[1] I use what I describe at
<URL:http://www.gossamer-threads.com/lists/mythtv/users/236245#236245>,
namely:

    mythtranscode -c xxxx -s yyyy-mm-dd-hh-mm-ss \
    -k -b -m -v important,general --showprogress

Here's an easy feature request for intrepid coders: Make User Jobs
callable from the OSD the way the built-in transcode options can be
done so as of 0.20, so I can add this as a User Job and call it on one
or more recordings at once directly from mythfrontend.

[2] A peculiarity in such cases is that bookmarks saved in such
recordings before the seektables are rebuilt totally confuse MythTV
afterward as it tries to match the nonsense location contained within
them to the newly-built correct seektable. Another feature request,
for which I have no idea how easy this would be: Prevent mythfrontend
from trying to jump to nonsense-bookmark locations within recordings.

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US