Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#6923 closed defect (invalid)

0.21->trunk DB upgrade failed

Reported by: warpme@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: MythTV - Mythtv-setup Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


Failure of 0.21-fixes DB upgrade via myhtv-setup to SVN21512. Log from mythtv-setup attached. It looks like upgrade procedure successfully adding "default_authority" colon but next error about existing "default_authority" colon is reported.

Attachments (2) (1.1 KB) - added by warpme@… 12 years ago.
Log from mythtv-setup runtime (1.3 KB) - added by warpme@… 12 years ago.
Log from clean upgrade

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by warpme@…

Attachment: added

Log from mythtv-setup runtime

comment:1 Changed 12 years ago by sphery

Milestone: 0.22unknown
Priority: blockerminor
Resolution: invalid
Severity: highmedium
Status: newclosed

The error "Duplicate column name 'default_authority'" would be impossible to get with an upgrade of a "clean" database--meaning something added that column to your schema before you ran mythtv-setup this time.

Since you're upgrading from schema version 1230 to 1242, where 1231--the one that adds the default_authority column--fails, one possible reason for this could be that you tried to upgrade, got a failure, then re-ran mythtv-setup to capture logs for uploading. If so, this failure is due to the fact that your database was in an "intermediate" state after the first (real) failure, having only completed some of the changes in the 1231 upgrade. Without logs showing the first/real failure, we can't track down the cause of that failure.

Another possibility is that some patch you may have applied to your local copy of MythTV may have added it and you didn't "clean up" your schema before the upgrade.

If you can get logs of the first real failure, please upload them and add a comment to the ticket. You may restore a backup of your 0.21-fixes database ( ). If you did not manually backup your database before upgrading, you may have gotten an automatic backup--check the directories in your DB Backups storage group or, if you haven't defined a DB Backups SG, check the directories in your Default storage group.

comment:2 Changed 12 years ago by warpme@…

Well, My setup is:

-0.21-fixes production BE

-trunk test BE running under vmware

According to Your suggestions I do following:

-stop msql/mythbackend in trunk based test BE

-rsync DB files from running, production 0.21-fixes BE to test BE

-start mysql on test BE

-launch mythtv-setup on test BE

Log attached...

Changed 12 years ago by warpme@…

Attachment: added

Log from clean upgrade

comment:3 Changed 12 years ago by warpme@…

Michael, Thx for quick replay ! Well - I do not apply 5603.

Infact only patches which I apply to my 0.21 are VDPAU/H264/AC3 related.

It seems to be strange as in original 0.21 DB there is no "channelscan_dtv_myltiplex" table at all, and "dtv_multiplex" table hasn't colon "default_authority".

After upgrade there is "channelscan_dtv_multiplex" table and also colon "default_authority" is added to "dtv_multiplex" table.

Maybe double presence of "default_authority" is root cause, or maybe adding table "channelscan_dtv_myltiplex" is confused by existence of "default_authority" in "dtv_multiplex"table ?

Anyway - maybe uploading my original DB will be helpful for You ?

If so, have we any kind drop-host for passing such 10M files ?


comment:4 Changed 11 years ago by sphery

This error seems to be relatively common and is due to restoring a 0.21-fixes DB on top of a 0.22 DB schema (such as the "blank" ones provided by distros/packages). The issue will occur for users who do a "binary" restore (copying the 0.21 binary MySQL data files on top of the 0.22 DB data files) as well as those who do a "SQL" restore (using a backup script). In the latter case--using a SQL restore of 0.21-fixes data into a 0.22-schema database--MySQL will do automatic conversions of data formats where the schema has changed and will cause data corruption.

Users restoring backups must DROP the old database before restoring the backup. Please see for more information, and please use the restore script to do the restore (as it performs sanity checks and alerts the user when something is wrong).

Note: See TracTickets for help on using tickets.