[mythtv-users] Skipping and time length messed up
Michael T. Dean
mtdean at thirdcontact.com
Sat Oct 24 17:27:21 UTC 2009
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.
> 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
And repeat it for each directory in each storage group.
More information about the mythtv-users