[mythtv-users] Skipping and time length messed up

[Tim Ashman]

On Saturday 24 October 2009 10:27:21 am Michael T. Dean wrote:
> On 10/24/2009 11:51 AM, Tim Ashman wrote:
> > On Friday 23 October 2009 01:02:06 pm Michael T. Dean wrote:
> >> On 10/23/2009 02:56 PM, Tim Ashman wrote:
> >>> Ok, I'll try that this weekend.  Is this rebuild function on the
> >>> backend or is it a mysql script, and if so where would it be located.
> >>
> >> http://www.mythtv.org/wiki/Repairing_the_Seektable
> >
> > I followed these instructions and was able to run the optimize command
> > however the rest of the doc talks about fixing specific files.  My
> > problem is that ever new recording has this problem so I think something
> > else is going on.
> >
> > Do you have another suggestion.  Maybe I need to rebuild the entire
> > database
>
> If you had a crashed recordedseek MySQL table, then all new recordings
> would have had missing/invalid seektables, so the optimize_mythdb.pl
> would fix the recordedseek table, then all new recordings would get
> proper seektables.  However, any recordings created while the table was
> crashed would have missing/invalid data--and potentially any of the
> recordings created before the crash could have lost data--so you'd have
> to recreate the seektable (using mythtranscode --buildindex once each
> for all MPEG-2 recordings or mythcommflag --rebuild for NUV files) for
> any affected recording.
>
> A new database won't help.  Dropping the recordedseek table and
> recreating it (or, if you /must/ do the wrong thing, at least just
> TRUNCATE the table), would be throwing out the baby with the
> bathwater--you'd lose all good seektables at the same time.
>
> If you don't care to determine which recordings are broken and would
> rather max out your CPU for a couple days or so, just write a script
> that runs mythtranscode --buildindex on every currently-existing recording:
>
> for recording in /path/to/recordings/directory/*.mpg; do
>   mythtranscode --mpeg2 --buildindex --allkeys \
>                 --showprogress --infile $recording
> done
>
> And repeat it for each directory in each storage group.
>
> Mike

ok, I don't really care about finding out which recordings are messed up.  I 
can find out by watching them and if the commercial skip works then it is 
fine it the first skip fails I'll know I can't do any seeking on this 
recording.  Since I delete almost every show after I've watched it it sounds 
like I should just see if it just works it way through.

My only concern would be what happens to those seek entries that are wrong 
after I delete the file (show) associated with them, does the logic of 
the "delete" also delete the incorrect records in the seek table because they 
are still marked with the correct show, or do these entries end up just 
hanging out making my table larger than it would otherwise be?

Thanks again for your help.

tim