[mythtv-users] mythv 0.25 issues

[Michael T. Dean]

On 04/08/2012 05:27 PM, Scott & Nicole Harris wrote:
>>>>>> 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.

You mean the scripts that check the database/schema to make sure you 
don't miss steps like dropping the database and that do a ton of other 
checks for things that users tend to forget that we've determined over 
the years cause problems after the restore "succeeds"?  ;)

>   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.

Well, if others have problems, please get me logs.  I keep hearing about 
issues, but haven't seen any usable bug reports or logs (and my 
upgrades--from 0.21 schema, until that was no longer supported for 
master and now from 0.22 schema--work perfectly with full plugin schemas 
and everything, and I do them about once a week to try to make sure 
there are no problems).  And my Magic 8 Ball hasn't been too helpful at 
finding issues, so I really need those logs.  :)

Mike