<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><br>
<br>
On 12/14/2014 07:06 PM, Dave Matthews wrote:<br>
> I did an upgrade from Ubuntu 12.02 32/MythTV .25 bit to Ubuntu 14.04<br>
> 64 bit/MythTV .27 and now have a database upgrade failure.  I think it<br>
> actually started at 1299 but there is no message about going from 1299<br>
> to 1300.  Just that it tried to get to 1301.  The .27 is from the<br>
> Ubuntu software center.<br>
><br>
> Text out of mythtv-setup:<br>
><br>
> Shall I upgrade this database? [yes]  2014-12-14 17:26:29.874638 C<br>
> Database Backup complete.<br>
> 2014-12-14 17:26:29.875128 C  Backed up database to file:<br>
> '/var/lib/mythtv/recordings/mythconverg-1300-20141214222611.sql.gz'<br>
> yes<br>
> 2014-12-14 17:50:06.643255 C  Upgrading to MythTV schema version 1301<br>
> 2014-12-14 17:50:06.643802 E  DB Error (Performing database upgrade):<br>
> Query was: ALTER TABLE channel ADD COLUMN iptvid SMALLINT(6) UNSIGNED;<br>
> Error was: Driver error was [2/1060]:<br>
> QMYSQL: Unable to execute query<br>
> Database error was:<br>
> Duplicate column name 'iptvid'<br>
><br>
> new version: 1301<br>
> 2014-12-14 17:50:06.643840 E  Database schema upgrade failed.<br>
> 2014-12-14 17:50:06.644392 E  Couldn't upgrade database to new schema<br>
> htpc@htpc:/home/mythtv$<br>
><br>
> I originally did the upgrade to Ubuntu 14.04 32 bit with a MythTV<br>
> build out of the repositories.  The db did a forward convert with no<br>
> problems but ALSA was not working.  I noticed the 32 bit (real old<br>
> install, started around MythTV 20 or less) and decided to do a clean<br>
> install.  I am using a backup of the 32 bit database.<br>
><br>
> What would be useful would be:<br>
> 1) What is the db upgrade script so I can run it and watch what is<br>
> happening?  If I just need to fix a few tables to let it run I am good.<br>
> 2) Alternatively all I really care about is access to the old<br>
> recordings.  I could let it build an empty .27 database and then<br>
> insert the data from the backup into the tables that point at the<br>
> recordings.  Can someone give the list of tables that need to be<br>
> populated to point at the old recordings?<br>
<br>
This almost always means that you ran mythbackend on the master host and<br>
it started upgrading the database, but before it could complete the<br>
process, something killed it--like a "just to make sure everything is<br>
working properly" monitor program or upstart's built-in daemon monitor<br>
or ... or even an impatient user who thinks "it must be locked up" or<br>
(and this may well be the problem) mythtv-setup (or some script that<br>
starts mythtv-setup/mythtv-setup.real, as provided by some distros) if<br>
it was started while the backend was doing the upgrade and it killed (on<br>
its own, as some scripts, or after prompting, if canonical mythtv-setup)<br>
mythbackend for the user.  Then, when you started mythtv-setup, it tried<br>
to upgrade the partially-upgraded-and-now-completely-broken database and<br>
failed because of the failed upgrade.<br>
<br>
So, the proper thing to do now is:<br>
<br>
a) shut down everything related to MythTV (all<br>
frontends/backends/clients/...)<br>
b) do a complete restore (<br>
<a href="https://www.mythtv.org/wiki/Database_Backup_and_Restore" target="_blank">https://www.mythtv.org/wiki/Database_Backup_and_Restore</a> ) of the last<br>
database backup to occur before *all* upgrade attempts (meaning before<br>
the original upgrade attempt that got cancelled, probably started by the<br>
master backend)<br>
c) start mythtv-setup and let it upgrade the database without interruption<br>
<br>
Since your initial database upgrade attempt(s) was interrupted, the<br>
state of your database (schema and data) is indeterminate, so the only<br>
proper solution is to go back to a known-good backup<br>
(pre-upgrade-attempts), and then do a successful upgrade.<br>
<br>
This is why I still want to remove all ability for mythbackend (on any<br>
host) to upgrade the database and require explicit upgrades.  Until I<br>
get permission, it's up to the users to make sure they (or their<br>
systems/scripts/...) don't interrupt upgrades (and/or don't ever start<br>
mythbackend until after the database upgrade has been performed using<br>
mythtv-setup).<br>
<br>
Mike<br>
<br></blockquote><div> </div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
</blockquote><div> </div><div>I was subscribed in digest mode so threading is probably broken.</div><div> </div><div>This is the best  database that I have so I need to manually fix it.  I will grep the sources to see where the alter table statements are stashed.  My other option is to just run select count (*) against all of the tables on the old database and see where the recorded shows data is held.  Then dump that, let the backend build a new database and just import the recorded shows back into a new database.  The only data that I care about is the recoreded shows.</div><div> </div><div>There is also something goofy with the downloads in the Ubuntu software center.  The mythtv account was not granted access to any of the tables.  I had to do manual grants before anything would happen.</div><div> </div><div>I totally agree that things like this should not kick off in the background (or in a gui).  For a normal user the setup just fails silently.</div><div><br>Dave</div></div></div></div>