[mythtv-users] Problem with latest run of optimize_mythdb.pl

[Hika van den Hoven]

Hoi Craig,

Sunday, December 27, 2015, 7:08:23 PM, you wrote:

> It looks like I could recover a lot of the data that was in the
> recordedseek table if I extract just that portion of the last good backup
> (made with mythconverg_backup.pl) and feed it back in to mysql as a command
> stream.  Are you aware of any reasons not to try that since I'm already
> manipulating the data in that table, anyway?

> Yesterday's backup was fine.  I run mythconverg_backup.pl once each day
> immediately after I run optimize_mythtdb.pl.  I discovered today's problem
> because the backup locked up and upon investigation I found the
> recordedseek problem in the optimize_mythdb.pl log.

> --
> Craig.

You can try, but I would choose the slow way and rebuild what I need.
Anyway, backup first!!!
Most will work without that table. Only skipping, and parsing through
a recording will be slow and/or inaccurate. Also you need to run
commflagging again on the recordings you want.
But if you set-up that userjob you can queue those jobs on the
recordings you expect to watch in the next day and then bit by bit
recreate for the other recordings. You should set a relevant limit on
the number of jobs running simultaneously so they don't interfere with
regular recordings. Or you can install Mythbackend on a spare machine
as a slave and set those two jobs (mythcommflagging and rebuilding the
seektables) to only run on that backend.

Tot mails,
  Hika                            mailto:hikavdh at gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens