Mailing List Archive

Warning before upgrading
Just a quick heads up to anyone who is upgrading to some version of
0.22-fixes or trunk.

Please make sure you:

a) Back up your database before upgrading (
http://www.mythtv.org/wiki/Database_Backup_and_Restore )

b) If you need to restore your database, DROP the old database before
restoring (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Database_Restore )

c) I highly recommend using the restore script to do any DB
restores--it does a bunch of sanity checks alerts you when something is
wrong (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Database_Restore )

d) Do not do a partial/"new hardware" restore--even if you're using
new hardware

e) If at all possible, do not change MythTV system host names (to keep
the upgrade as simple as possible)

Mike




Details for those who want them:

If you're not doing an "in-place" upgrade (so you need to restore your
DB backup), it is critical that you DROP any existing database /before/
restoring your database backup. There have been several cases of users
getting failed DB upgrades because they restored their 0.21-fixes backup
on top of a 0.22 "blank" database provided by a distro/packages--meaning
that MySQL incorrectly stuffs 0.21-fixes data into a 0.22+ schema
version (thereby corrupting data). Furthermore, after doing so, the DB
schema changes will fail--in this case, the DB upgrade fails with the
error, "Duplicate column name 'default_authority'."

Note that a full restore is recommended. There's no real reason to do a
partial/"new hardware" restore. Definitely do not do "23.7 Moving your
data to new hardware" at
http://www.mythtv.org/docs/mythtv-HOWTO-23.html#ss23.7 . Doing so will
corrupt your data. Even if you use the restore script to do a partial
restore (so the data is not corrupted), a partial restore requires a
very much more complex approach to upgrading and requires that you
completely reconfigure your system after upgrade. In short, don't do a
partial restore.

If you change hostnames on a MythTV system, it is critical that you
update all the data in the database to change the old hostname to the
new hostname so recordings, settings, keybindings, jumppoints, and
/much/ more are properly found for the host. Doing so is not
straightforward--do /not/ do so manually through SQL. Instead, use the
restore script to change the hostname (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
). However, it is critical that you change the hostname after restoring
the database but /before/ running any mythtv applications
(mythfrontend/mythbackend/mythtv-setup) on the host with the new
hostname. If you forget to do so, changing the hostname becomes /much/
more difficult--to the point that restoring your pre-upgrade backup and
doing the upgrade properly, and using the script to change the hostname,
is the easiest solution.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Warning before upgrading [ In reply to ]
On Mon, Nov 2, 2009 at 1:07 PM, Michael T. Dean <mtdean@thirdcontact.com> wrote:
>  e) If at all possible, do not change MythTV system host names (to keep the
> upgrade as simple as possible)
>
> If you change hostnames on a MythTV system, it is critical that you update
> all the data in the database to change the old hostname to the new hostname
> so recordings, settings, keybindings, jumppoints, and /much/ more are
> properly found for the host.  Doing so is not straightforward--do /not/ do
> so manually through SQL.  Instead, use the restore script to change the
> hostname (
> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
> ).  However, it is critical that you change the hostname after restoring the
> database but /before/ running any mythtv applications
> (mythfrontend/mythbackend/mythtv-setup) on the host with the new hostname.
>  If you forget to do so, changing the hostname becomes /much/ more
> difficult--to the point that restoring your pre-upgrade backup and doing the
> upgrade properly, and using the script to change the hostname, is the
> easiest solution.


I inadvertantly did this when I created a new system then imported a
couple of tables from my old system. Suprisingly I've noticed no
negative effects but I will go through and attempt to straighten it
out anyhow. Thanks for the heads up.

Ron
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Warning before upgrading [ In reply to ]
On 11/02/2009 05:33 PM, Ron Garrison wrote:
> On Mon, Nov 2, 2009 at 1:07 PM, Michael T. Dean <mtdean@thirdcontact.com> wrote:
>
>> e) If at all possible, do not change MythTV system host names (to keep the
>> upgrade as simple as possible)
>>
>> If you change hostnames on a MythTV system, it is critical that you update
>> all the data in the database to change the old hostname to the new hostname
>> so recordings, settings, keybindings, jumppoints, and /much/ more are
>> properly found for the host. Doing so is not straightforward--do /not/ do
>> so manually through SQL. Instead, use the restore script to change the
>> hostname (
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
>> ). However, it is critical that you change the hostname after restoring the
>> database but /before/ running any mythtv applications
>> (mythfrontend/mythbackend/mythtv-setup) on the host with the new hostname.
>> If you forget to do so, changing the hostname becomes /much/ more
>> difficult--to the point that restoring your pre-upgrade backup and doing the
>> upgrade properly, and using the script to change the hostname, is the
>> easiest solution.
>>
> I inadvertantly did this when I created a new system then imported a
> couple of tables from my old system. Suprisingly I've noticed no
> negative effects but I will go through and attempt to straighten it
> out anyhow. Thanks for the heads up.

In some configurations Myth will weather the changes to hostname without
issue. Basically though, in more complex configurations--with multiple
hosts and non-local storage--you can have issues.

If you haven't noticed any issues, your best bet is likely to leave it
as it.

If you do notice issues, you can use the restore script (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
) to change the current/"new" hostname to some "garbage" value then
change the old hostname to the new hostname.

So, say your old hostname was ancient and your new (and desired)
hostname is cuttingedge, you could use:

mythconverg_restore.pl --change_hostname --old_hostname="cuttingedge"
--new_hostname="unusedgarbage" &&
mythconverg_restore.pl --change_hostname --old_hostname="ancient"
--new_hostname="cuttingedge"

That way, everything associated with ancient is now associated with
cuttingedge, but the new stuff created for cuttingedge before you did
the name change gets moved out of the way. The "unusedgarbage" data
will still be in the database, but it won't take much space at all
(we're talking a few kilobytes of HDD space).

The big problem, though, is if the host with the changed name is
actually a backend, it will be recording new shows and storing the
"current" hostname with that information. So, if you had shows
associated with ancient and new ones associated with cuttingedge, you
won't be able to properly fix the issue with the current script. But,
since Storage Groups were designed to be very flexible, they may figure
everything out for you. If they seem to be doing so, don't try to
change the hostname for the old information.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Warning before upgrading [ In reply to ]
Hi Mike,

> Just a quick heads up to anyone who is upgrading to some version of
> 0.22-fixes or trunk.
>
> Please make sure you:
>
> a) Back up your database before upgrading (
> http://www.mythtv.org/wiki/Database_Backup_and_Restore )
>
> b) If you need to restore your database, DROP the old database
> before restoring ( http://www.mythtv.org/wiki/Database_Backup_and_Restore#Database_Restore
> )
>
> c) I highly recommend using the restore script to do any DB
> restores--it does a bunch of sanity checks alerts you when something
> is wrong ( http://www.mythtv.org/wiki/Database_Backup_and_Restore#Database_Restore
> )
>
> d) Do not do a partial/"new hardware" restore--even if you're using
> new hardware
>
> e) If at all possible, do not change MythTV system host names (to
> keep the upgrade as simple as possible)

I restore my database using your script successfully.
However, when I restart mythbackend afterward, I get the error:

2009-11-03 14:34:50.259 Newest MythTV Schema Version : 1244
2009-11-03 14:34:50.291 Upgrading to MythTV schema version 1171
2009-11-03 14:34:50.320 DB Error (Performing database upgrade):
Query was: INSERT storagegroup (groupname, hostname, dirname) SELECT DISTINCT 'Default', hostname, data FROM settings WHERE value = 'RecordFilePrefix' AND hostname IS NOT NULL AND hostname <> '';
Error was: Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry 'Default-asus-/video/mythvideo/' for key 'grouphostdir'
new version: 1171
2009-11-03 14:34:50.343 Database Schema upgrade FAILED, unlocking.
2009-11-03 14:34:50.360 Couldn't upgrade database to new schema

after which the backend retries in an endless loop.

I was actually planning to upgrade the system with only the most necessary things included
and reconfiguring completely. This is because over time the system has become quite
slow (deleting a recording can take up to 10 seconds of unresponsiveness with
mysql at 100% cpu). So I thought that this might be a good oppertunity to start
fresh.
But apparently this is not such a good idea.

Any ideas what _would_ be a good approach (to solving both problems, preferably).

Thanks,

Ronald
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users