[mythtv-users] Problem upgrading from 0.24 fixes to 0.25 schema 1266 to 1299

Wed Apr 11 18:23:17 UTC 2012

Hi Mike - in terms of the upgrade I shut down the other machine using 
the backend (I have two machines, one a FE and the other a BE), then 
did the apt-get type upgrade and found I had the issue.  So I then 
killed off all the myth processes on the single remaining machine, 
restore the DB and ran the script.

I can certainly send you the DB and that is a generous offer which I 
really appreciate.  Hopefully the following link gives this to you.

http://dl.dropbox.com/u/1847528/mythconverg-1264-20120411120545.sql.gz

Regards

Dave

On Thursday, 12 April 2012 5:39:43 a.m., Michael T. Dean wrote:
> On 04/11/2012 06:02 AM, david.medland-slater wrote:
>> On Wednesday, 11 April 2012 6:57:44 p.m., Michael T. Dean wrote:
>>> On 04/11/2012 02:54 AM, Michael T. Dean wrote:
>>>> On 04/11/2012 01:18 AM, david.medland-slater wrote:
>>>>> Thanks Mike! I got a couple of other errors which I cleared up by
>>>>> adding the following horribly inefficent statements and it seems to
>>>>> have burst into life OK.
>>>>>
>>>>> I shall keep that DB just in case. That help was really appreciated
>>>>>
>>>>> ALTER TABLE oldrecorded DROP COLUMN future;
>>>>> alter table record drop column autometadata;
>>>>> ALTER TABLE record DROP COLUMN filter;
>>>>> alter table record drop column inetref;
>>>>> alter table recorded drop column inetref;
>>>>> alter table oldrecorded drop column inetref;
>>>>> alter table record drop column season;
>>>>> alter table recorded drop column season;
>>>>> alter table oldrecorded drop column season;
>>>>> alter table record drop column episode;
>>>>> alter table recorded drop column episode;
>>>>> alter table oldrecorded drop column episode;
>>>>> drop table recordedartwork;
>>>>> DELETE FROM recordfilter where filterid>=0 and filterid<=5;
>>>>
>>>> All of the errors that would be "fixed" (worked around is a better
>>>> word, probably) by those statements are impossible /unless/ you're
>>>> stopping and re-starting the upgrade--such that when you stop it, you
>>>> corrupt the state of the database. (And each of the changes
>>>
>>> that you undid were ones that came later than the database upgrade
>>> that was failing, before, which means it wasn't just a case of not
>>> restoring the 1264 database.)
>>>
>>>>
>>>> If a database upgrade fails--or is somehow interrupted (by killing
>>>> the backend/mythtv-setup or whatever), the only supported (and only
>>>> reasonable) fix is restoring the pre-upgrade database backup and then
>>>> trying again, but ensuring that nothing kills the
>>>> backend/mythtv-setup during the upgrade.
>>>>
>>>> I would /not/ trust the state of my database if I were you. I highly
>>>> recommend repeating the instructions I provided before and watching
>>>> log output when the upgrade is proceeding and ensuring that you/your
>>>> start scripts don't kill the upgrade.
>>>>
>>>> I'm really starting to think someone wrote a seriously broken start
>>>> script that kills the backend or mythtv-setup or whatever after some
>>>> short(er than it takes to upgrade the database) time if it thinks
>>>> it's not responding.
>>>>
>>>> I'm guessing the brokenness is in some mythbackend start script. In
>>>> which case /every/ user on that distro should be using mythtv-setup
>>>> to upgrade their database (and I really home there's not a similarly
>>>> broken mythtv-setup start script).
>>>
>>> What distro are you using? What did you use to upgrade your database?
>>>
>>> And, most importantly, do you still have that 1264 database backup to
>>> go back to. :)
>>>
>>
>> Yes indeed I spoke too soon Mike. I have found I have nothing in my
>> list of scheduled recordings...it's empty as far as mythtv and
>> mythweb are concerned.
>>
>> To recap I restored the DB each time before running my amended
>> script. Found any errors, then added 'suitable' SQL, restored back to
>> the manual backup I had taken before the upgrade and so on. Once I
>> got to the point of having no errors I again restored the DB one more
>> time and reran.
>>
>> I am running mythbuntu and I did the upgrade by running mythbackend
>> interactively with no other copy or myth apps running at the time. I
>> actually made two manual copies of the pre-upgrade DB, just to be
>> sure, to be sure. And at this stage I am very tempted to roll back. A
>> shame, but I brought it on myself.
>>
>> The other thing I noticed is that in the mythbackend log I get a
>> constant cycle of the following :-
>>
>> 2012-04-11 21:55:57.270396 N Connecting to master server: mythtv:6543
>> 2012-04-11 21:55:57.270604 N Connected successfully
>> 2012-04-11 21:56:27.274700 E MythSocket(ffffffffb46334d8:36):
>> readStringList: Error, timed out after 30000 ms.
>> 2012-04-11 21:56:27.274791 E MainServer: Failed to open master server
>> socket, timeout
>> 2012-04-11 21:56:27.275324 I adding: mythtv as a slave backend server
>> 2012-04-11 21:56:27.275566 W MainServer: Unknown socket closing
>> MythSocket(0xffffffffb4662940)
>> 2012-04-11 21:56:27.276671 E MythSocket(ffffffffb4662940:-1):
>> writeStringList: Error, socket went unconnected.
>> We wrote 0 of 10 bytes with 1 errors
>> starts with: 2 OK
>> 2012-04-11 21:56:28.275590 N Connecting to master server: mythtv:6543
>> 2012-04-11 21:56:28.275795 N Connected successfully
>> 2012-04-11 21:56:58.276420 E MythSocket(ffffffffb4660ff0:36):
>> readStringList: Error, timed out after 30000 ms.
>> 2012-04-11 21:56:58.276512 E MainServer: Failed to open master server
>> socket, timeout
>> 2012-04-11 21:56:58.276990 I adding: mythtv as a slave backend server
>> 2012-04-11 21:56:58.277147 W MainServer: Unknown socket closing
>> MythSocket(0xffffffffb46a8938)
>> 2012-04-11 21:56:58.278248 E MythSocket(ffffffffb46a8938:-1):
>> writeStringList: Error, socket went unconnected.
>> We wrote 0 of 10 bytes with 1 errors
>> starts with: 2 OK
>
> David,
>
> I wonder if maybe upstart decided to start mythbackend while you were
> running it interactively, elsewhere? What did you do to disable the
> automatic startup? While we do attempt to check that "no one else" is
> upgrading the DB before starting an upgrade, there are ways that the
> check can fail--especially on long upgrades.
>
> Is there any chance you can get me a copy of the pre-upgrade DB backup
> (you can send a link directly to me--off list--as a reply to this
> message)? I'd like to verify that the upgrade succeeds (and, if you
> like, I can even make the upgraded version available to you, again, to
> restore onto your system so you know you have a good schema).
>
> If the upgrade fails, I can fix any issues in the upgrade procedure.
> If, however, it succeeds, we can keep trying to guess what's happening.
>
> Thanks,
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium