[mythtv-users] mythv 0.25 issues

[Scott & Nicole Harris]

>>>>> So it is very strange that mythtv-setup does not create proper schema 
>>>>> ?
>>>>> On new setup I had start mythbackend in order to get proper database 
>>>>> config and then run mythtv-setup.
>>>>> Another issue is that I can't get lineup from schedule direct at all 
>>>>> works fine with 0.24 fixes.
>>>>> I have pfsense running with antivirus and squid. I wonder if anyone 
>>>>> has any idea on how I can fix that issue.
>>>>> Upgrading from 0.24 fixes to 0.25 creates database error issue.
>>>>
>>>> I had the db error issues as well.  I had to start mythbackend from the 
>>>> command line to see what was going on then manually drop tables / 
>>>> columns one at a time as it complained about it and failed until it 
>>>> stopped complaining.  The problem is, if it fails part way through, but 
>>>> say has already added a new table or a new column to an existing table, 
>>>> then next time through, it isn't happy because things it's trying to do 
>>>> (again) have already been done.
>>
>>> Exactly, which is why, if you have a failed DB update, you need to 
>>> restore the pre-upgrade backup and then try a new upgrade.  We don't 
>>> support upgrading partially upgraded databases--because we have 
>>> absolutely no checking for what failed and what succeeded and we don't 
>>> have transaction support, so the schema is always in an unknown 
>>> condition when a DB upgrade fails.
>>
>> When I upgraded my production setups to 0.25, I spent 2+ hours that 
>> morning on a fresh installation of Mythbuntu trying to get the upgrade to 
>> go through, having it fail, restoring my original 0.24 db...rinse, wash, 
>> repeat before I threw in the towel and manually addressed each issue it 
>> complained about.  "Can't do x because y already exists" -> drop y, try 
>> again -> "can't do a because b.c already exists" -> remove column b.c, 
>> try again, etc). After about 5 iterations of addressing complaints, it 
>> finally succeeded.

>Note that you should never--with a proper database schema--get such a 
>message (proper schema means, also, no failed DB upgrades with that 
>schema).  However, it's quite easy to get them when you restore a DB backup 
>of a 0.24-fixes system, for example, on top of a "pre-created by the 
>distro/package-manager" 0.25 schema (as you might get on a "new 
>install"--versus just upgrading MythTV on an existing system).  What you 
>should do when restoring a database backup on top of an existing schema is 
>the "replace" option:

>http://www.mythtv.org/wiki/Database_Backup_and_Restore#Replacing_an_existing_database

>And, as far as 0.25 goes, nothing in the 0.25 upgrades should cause any 
>issues with any 0.24 database.  So, could it have just been something like 
>the above?

I don't use the backup / restore scripts when doing my upgrades.  I just use 
the MySQL Workbench and do a backup to a "safe" location (i.e. somewhere 
Myth won't ever touch during any procedures I am about to embark on) 
immediately before I begin the fun.  When restoring I also use the MySQL 
Workbench, but having been stung way back in the ~.20 -> 0.21 era, I am 
careful to "DROP IF EXISTS mythconverg" and usually manually drop the 
mythconverg schema myself with the Workbench before importing, which I would 
assume (knowing full well what assume makes of you and me ;)) amounts to the 
same as the "replace" option of the restore script.

Having said that, did I do it this time?  I think so, but it was a Saturday 
morning too :).

>If there are problems, though, I can't fix them unless someone reports 
>them.

Fair enough, I probably should have posted logs.  Sometimes when I 've been 
frustrated by something, I'm just happy to have gotten it resolved on my own 
and move on.