[mythtv-users] Strange seeking following database crash

[Michael T. Dean]

On 01/22/2013 05:42 AM, Ian Oliver wrote:
> Michael T. Dean wrote:
>> Yes.  Just run mythcommflag --rebuild on each affected recording--or, if
>> you prefer, on every single recording (and then wait a few days for
>> things to go back to normal).
> OK, done, and it only took a few hours.
>
> I am however unsure as to why this data is needed. I don't do commercial skipping,
> and the seek data isn't required for video played from my SMB share, so why does
> mythtv need it for recordings? And what happens when you do chase play, so watching
> something that's still recording?

Seek data allows for very fast, exact seeking in video with variable 
bitrates.  Without it, seeking is much slower as it requires either 
decoding all the video from the current position to the later position 
to which you're seeking or guessing a position which should be a little 
bit before where you're attempting to seek (forward or backward) and 
then decoding video until we find the position you've requested.  The 
seek data isn't required, but if it's there, it's used--so if it's 
corrupt/bad/missing data, seeking doesn't do what you expect.

>> Then, the 2nd thing you need to do is:
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore (specifically the
>> part at
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Automating_Database_Backups
>> ).  :)
> That's how I spotted the corruption.
>
> A regular backup ran, created a 3.5GB backup of my database rather than the usual
> 23MB one, filled the disk, and also caused some mayhem due to my database backup
> being in a dropbox directory that's synced to other machines.
>
> After the repair, the database backup dropped to 15MB and I did consider restoring an
> old database. However, we'd made several recordings since the backup, and I wasn't
> sure how to get these back into the database,

Yeah, the only supported approach is to take the new recordings and add 
them to Video Library (the location where user-provided, user-managed 
video is stored).  Often when I'm in this position and I have a lot of 
prior recordings of the show, I use the opportunity to just move the 
series to Video Library.

>   so I got my wife to spend half an hour
> checking everything looked OK and we went ahead without the restore.
>
> To be fair, it's all been fine for a couple of weeks and it's only the seeking
> problem that's suggested a restore might have been better.

If that was the only crashed/corrupt table, you should be OK.  If not, 
you may have lost some data in other tables, so if you find other things 
fail to work, make sure you closely re-check the configuration of the 
related pieces.

Mike