[mythtv-users] Problem upgrading from 0.24 fixes to 0.25 schema 1266 to 1299
Michael T. Dean
mtdean at thirdcontact.com
Wed Apr 11 17:39:43 UTC 2012
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
More information about the mythtv-users
mailing list