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

david.medland-slater at inbox.com david.medland-slater at inbox.com
Wed Apr 11 10:02:18 UTC 2012


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




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. :)
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!




More information about the mythtv-users mailing list