[mythtv-users] Warning before upgrading

[Ronald Pijnacker]

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