[mythtv-users] 0.26 Upgrade caused Seek Tables missing from recordings

[Anthony Giggins]

On 20 May 2013 10:15, Michael T. Dean <mtdean at thirdcontact.com> wrote:

> On 05/17/2013 07:42 AM, Anthony Giggins wrote:
>
>> Hi All,
>>
>> I recently upgraded from 0.25.3 and noticed that all the seek tables from
>> recordings made before the upgrade are missing.
>>
>> Now I believe I can rebuild them all via mythcommflag --rebuild
>>
>> But is this a known issue?
>>
>
> This was an issue with revisions of pre-0.26 unstable/development code
> (master branch) and it was fixed within 24 hours of initial commit (meaning
> there are only a few ancient revisions of master that were affected).
>
>
>  or something wrong during my upgrade?
>>
>
> Almost definitely.  Likely the upgrade was interrupted by you or some
> over-zealous start script/monitor application killing the backend when it
> was upgrading.  (That specific example is one reason why you should always
> use mythtv-setup to upgrade your database and never use mythbackend to do
> so.)
>
>
>  I didn't see anything about this in the release notes...
>>
>> http://www.mythtv.org/wiki/**Release_Notes_-_0.26<http://www.mythtv.org/wiki/Release_Notes_-_0.26>
>>
>> also I noticed that mythweb is showing alot more history from the
>> jobqueue then normal maybe a symtom of the same issue?
>>
>> Before anyone asks yes I did Import the Mysql timezone tables
>> http://www.mythtv.org/wiki/**MySQL_Time_Zone_Tables<http://www.mythtv.org/wiki/MySQL_Time_Zone_Tables>
>>
>> however awhile ago when this upcoming behavour was announced.
>>
>>
> If the time zone tables weren't properly in place, MythTV would have
> refused to do the database schema upgrade, so that shouldn't be the problem.
>
> You can just rebuild the seek tables, but if that particular (major) issue
> occurred during the upgrade, who knows what else may be broken in your
> database (schema and/or data).
>
> If you want to ensure that you have a proper schema and data, you can do a
> partial restore of a new database backup ( http://www.mythtv.org/wiki/**
> Database_Backup_and_Restore#**Partial_restore_of_a_backup<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup>), but note that doing so will require you to reconfigure /everything/
> (capture cards, video sources, input groups, channels, storage groups, all
> settings, all plugin data, etc.) on all backends and frontends after the
> partial restore.  Also, after doing so, you'll still want to do a seek
> table rebuild for all your recordings.  (The partial restore will correct
> the DB schema and the seek table rebuild will correct the corrupt data--at
> least the corrupt data you've identified, the seek table data.)
>
> Alternatively, you can run with your current database after doing the seek
> table rebuild and hope that you don't later find a problem (especially a
> larger problem that corrupts recording data that may not be re-creatable).
>
> Mike
>
>
Thanks for the reply, I only updated just before I posted my email.

all good, just rebuilt all the seek tables

ie. find /storage2/recordings/*.mpg -maxdepth 1 -type f -exec mythcommflag
--rebuild -f {} \; > results.out

Cheers,

Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130520/01e1fee6/attachment.html>