Author |
Message |
goofee
|
Posted: Tue Jul 08, 2008 2:16 pm |
|
Joined: Sat Feb 03, 2007 12:52 am
Posts: 187
Location:
Manitoba, Canada
|
I tried to upgrade from R5F27 to R5.5 and after it did the restore the screen kept scrolling that it couldn't connect to the database. Here's what is repeated in restore.log
Quote: Would you like to configure the database connection now? [yes] [console is not interactive, using default 'yes'] Database host name: [192.168.0.120] [console is not interactive, using default '192.168.0.120'] Should I test connectivity to this host using the ping command? [yes] [console is not interactive, using default 'yes'] Database non-default port: [0] [console is not interactive, using default '0'] Database name: [mythconverg] [console is not interactive, using default 'mythconverg'] Database user name: [mythtv] [console is not interactive, using default 'mythtv'] Database password: [mythtv] [console is not interactive, using default 'mythtv'] Unique identifier for this machine (if empty, the local host name will be used):
[console is not interactive, using default ''] Would you like to use Wake-On-LAN to retry database connections? [no] [console is not interactive, using default 'no'] QSqlQuery::exec: database not open QSqlQuery::exec: database not open
Cannot login to database?
Any suggestions?
Thanks.
|
|
Top |
|
|
ceenvee703
|
Posted: Tue Jul 08, 2008 2:30 pm |
|
Joined: Fri Apr 02, 2004 10:08 am
Posts: 1637
Location:
Virginia, USA
|
I have bad news for you.
I saw the same error as part of testing. Your log will eventually fill with the error. No one else saw the same error, and no one really knew why it happened or how to work around it. I got it consistently when trying to do an auto-upgrade.
You might be able to do a manual upgrade and save your recordings, but someone else would have to tell you how to do that, I just backed up videos and other non-recordings and did a clean install.
PS: What kind of hardware are you running? Maybe something about our particular setup is causing the error. I am using a Biostar TF7025-M2 motherboard (using the on-board Geforce video), a low-wattage AMD Athlon 64 X2 Dual-Core BE-2350, and a Western Digital WD5000AACS 500GB SATA "green" drive.
|
|
Top |
|
|
tjc
|
Posted: Tue Jul 08, 2008 7:11 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
My broad outline for troubleshooting this would go like this:
- Login as root, (I recommend via ssh)
- Stop all the the MythTV components.
- Stop and restart the mysql server. Make sure that you can connect to the DB with the mysql client program.
Code: /usr/bin/mysql -u root mythconverg -e "show tables" This should list about 100 tables. If it doesn't let me know. - Run the checkrestore script. If it fails let me know. - Manually start the mythbackend as mythtv in verbose mode. It should either fail to connect to the DB and say why, or start trying to do the auto upgrade. I'm guessing that the config files that tell it how to connect to the db are horked up. The files should look something like this: Code: root@black2:/home/mythtv/.mythtv# more mysql.txt DBHostName=localhost DBUserName=mythtv DBPassword=mythtv DBName=mythconverg DBType=QMYSQL3
# Set the following if you want to use something other than the # machine's real hostname for identifying settings in the database. # This is useful if your hostname changes often, as otherwise # you'll need to reconfigure mythtv (or futz with the DB) every time. # TWO HOSTS MUST NOT USE THE SAME VALUE # #LocalHostName=my-unique-identifier-goes-here
# If you want your frontend to be able to wake your MySQL server # using WakeOnLan, have a look at the following settings: # # Set the time the frontend waits (in seconds) between reconnect tries. # This should be the rough time your MySQL server needs for startup #WOLsqlReconnectWaitTime=0 # # # This is the amount of retries to wake the MySQL server until the frontend # gives up #WOLsqlConnectRetry=5 # # # This is the command executed to wake your MySQL server. #WOLsqlCommand=echo 'WOLsqlServerCommand not set'
root@black2:/home/mythtv/.mythtv# more config.xml <Configuration> <UPnP> <UDN> <MediaRenderer>fc9608e0-b961-46f4-b86b-f327fe30ef37</MediaRenderer> </UDN> <MythFrontend> <DefaultBackend> <DBHostName>localhost</DBHostName> <DBUserName>mythtv</DBUserName> <DBPassword>mythtv</DBPassword> <DBName>mythconverg</DBName> <DBPort>0</DBPort> </DefaultBackend> </MythFrontend> </UPnP> </Configuration>
if you've dorked with your DB username/password that's one likely cause of trouble. If you've done something bad to your /etc/hosts file that is another. if you don't see localhost and your hostname listed as 127.0.0.1 then that's a good place to start. Code: root@black2:/home/mythtv/.mythtv# grep localhost [color=red]/etc/hosts[/color] 127.0.0.1 black2 localhost ::1 ip6-localhost ip6-loopback
|
|
Top |
|
|
goofee
|
Posted: Wed Jul 09, 2008 12:01 pm |
|
Joined: Sat Feb 03, 2007 12:52 am
Posts: 187
Location:
Manitoba, Canada
|
tjc - I was able to connect to the sql database both as root and as mythtv using mythtv as password. mythconverg was there and there were 97 tables. I had played with my hosts file but only as described in the LinHES tutorial in mythweb, my hostname was at 127.0.0.1. mysql.txt looked like your example except instead of DBHostName=localhost it had the actual ip address.
I had been playing around with it before I got your response so thought I would try a fresh upgrade and see what those files said from there. Right away I got "starting restore"," testing restore", "restore fail" all playing at the same time, but the installer carried on. Logged in via SSH to check backup files..PANIC. Every thing was empty, lost all recordings. After the initial panic, I discovered that /dev/hda3 was mounted in /media not /myth. Fixed that. I now had a fresh install of R5.5 running, so from the menu chose restore. All my recordings work but the tuner is listed as unavailable. I'm guessing cause I restored a .20.1 database into a .21 system. Tried dropping the tuner and redoing it but no dice. I have some stuff set to record tonight so unless someone can help me fix this then I'll try downgrading to F27 tonight then try it all again tomorrow. If that doesn't work I'll have to try to program the VCR. shudder.
ceenvee703- here is my hardware, the only thing I noticed the same was a Western Digital 500 gig drive but mine is not SATA.
ECS K7SOM+
Onboard AMD Duron 1200 "factory tuned" to 1800
512 + 128 RAM
EVGA MX4000 PCI 128MB Svideo out
PVR150
|
|
Top |
|
|
tjc
|
Posted: Wed Jul 09, 2008 6:21 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
goofee wrote: mysql.txt looked like your example except instead of DBHostName=localhost it had the actual ip address. Definitey try localhost. There are a couple reasons this might work differently. 1) My recollection is that for localhost it's clever enough to use a Unix domain socket which avoids a number of potential TCP/IP issues. 2) If you're using DHCP the IP address might very well change. goofee wrote: Right away I got "starting restore"," testing restore", "restore fail" all playing at the same time, but the installer carried on. Logged in via SSH to check backup files..PANIC. Every thing was empty, lost all recordings. After the initial panic, I discovered that /dev/hda3 was mounted in /media not /myth. Only to be expected... If the system can't find the backup files in /myth/backup bad things happen. This is noted rather prominently in the hints and backup/restore notes. The installer doesn't halt when this happens because there are a couple ways that you can use it to do something clever. goofee wrote: All my recordings work but the tuner is listed as unavailable. I'm guessing cause I restored a .20.1 database into a .21 system. Tried dropping the tuner and redoing it but no dice.
The mythbackend server _should_ automatically upgrade your schema to the current version, so the problem is likely something else. Try the "drop all" instructions and be sure that you correctly reestablish your listing source and input connections too. I need to go back into work until much later tonight but I'll try to provide whatever troubleshooting help I can.
|
|
Top |
|
|
ceenvee703
|
Posted: Wed Jul 09, 2008 7:55 pm |
|
Joined: Fri Apr 02, 2004 10:08 am
Posts: 1637
Location:
Virginia, USA
|
tjc wrote: goofee wrote: mysql.txt looked like your example except instead of DBHostName=localhost it had the actual ip address. Definitey try localhost.
But I thought that this value is supposed to be changed from localhost to the backend IP# when you configure mythtv via setup->general. (going to include a link to a testers discussion here, tjc and other testers should be able to follow it.)
I have a vested interest in getting this figured out since I'm confident I'll have the same problem as goofee when I decide to auto-upgrade to 5.5.
|
|
Top |
|
|
mythedoff
|
Posted: Wed Jul 09, 2008 8:26 pm |
|
Joined: Mon Jul 31, 2006 10:41 pm
Posts: 149
|
This sounds like the problem I also had with my setup. I tried two things and both worked.
On the backend in /etc/mysql/my.cnf
I first tried commenting out:
#bind-address = 127.0.0.1
This worked, but then I tried:
bind-address = ip-of-backend
and it too worked.
|
|
Top |
|
|
tjc
|
Posted: Wed Jul 09, 2008 10:58 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
Yes. That makes perfect sense. One of those networking subtleties that I internalized long enough ago that it's instinctive and it doesn't even occur to me that it's not obvious to others....
When you bind/listen to a particular address for your host you're also implying a certain network interface (device). In this case 127.0.0.1 is lo0, and other address (lets say 192.168.0.101) is eth0. Unless there's a route or forwarding defined listening on 127.0.0.1 and trying to connect to 192.168.0.101 is like trying to call your POTS land line by dialing the mobile number. You really don't want to try to mix localhost/127.0.0.1/lo0 with joehosthere/192.168.0.101/eth0. This makes more sense when you think about a multi-homed machine with multiple NICs acting as a gateway or firewall. You really don't want stuff going from interface to interface outside of the controlled paths you set up explicitly. For example, just because you've got an FTP proxy facing your users inside doesn't mean you want someone in the DMZ to be able to bounce off of it and look like a user from a trusted site...
Unfotunately I'm a bit brain fried so this may not be a very clear explanation....
|
|
Top |
|
|
goofee
|
Posted: Thu Jul 10, 2008 5:52 pm |
|
Joined: Sat Feb 03, 2007 12:52 am
Posts: 187
Location:
Manitoba, Canada
|
Well the downgrade to R5F27 didn't work either.
I tried R5.5 again. When asked for root password I took the time to check some files and they were all as tjc posted. I commented out the bind address in /etc/mysql/my.cnf and restarted mysql server. After it restored my files I check and /home/mythtv/.mythtv/mysql.txt had an actuall IP address for hostname. I changed it back to localhost and restarted mysql again before continuing with the rest of the install. It never went into the infinite loop as it did before but got to upgrading DB schema. It proceded to draw dots across the screen. I let it run for an hour but I doubt it should take that long. This is some of what I found in /var/log/mythtv/mythbackend.log
Quote: 2008-07-09 23:30:27.929 Using runtime prefix = /usr 2008-07-09 23:30:27.974 Empty LocalHostName. 2008-07-09 23:30:27.976 Using localhost value of goofee.no-ip.info 2008-07-09 23:30:28.167 New DB connection, total: 1 2008-07-09 23:30:28.191 Connected to database 'mythconverg' at host: localhost 2008-07-09 23:30:28.200 Closing DB connection named 'DBManager0' 2008-07-09 23:30:28.208 Connected to database 'mythconverg' at host: localhost 2008-07-09 23:30:28.245 New DB connection, total: 2 2008-07-09 23:30:28.248 Connected to database 'mythconverg' at host: localhost 2008-07-09 23:30:28.257 Current Schema Version: 2008-07-09 23:30:28.261 DataDirectProcessor::FixProgramIDs() -- begin 2008-07-09 23:30:28.265 New DB DataDirect connection 2008-07-09 23:30:28.267 Connected to database 'mythconverg' at host: localhost 2008-07-09 23:30:28.272 DB Error (Fixing program ids in recorded): Query was: UPDATE recorded SET programid=CONCAT(SUBSTRING(programid, 1, 2), '00', SUBSTRING(programid, 3)) WHERE length(programid) = 12 Driver error was [2/1146]: QMYSQL3: Unable to execute query Database error was: Table 'mythconverg.recorded' doesn't exist
2008-07-09 23:30:28.286 DB Error (Clear setting): Query was: DELETE FROM settings WHERE value = 'BackupDBLastRunStart' AND hostname is NULL; Driver error was [2/1146]: QMYSQL3: Unable to execute query Database error was: Table 'mythconverg.settings' doesn't exist
2008-07-09 23:30:28.288 DB Error (SaveSettingOnHost query failure: ): Query was: INSERT INTO settings (value,data,hostname ) VALUES ( 'BackupDBLastRunStart', '2008-07-09 23:30:28', NULL ); Driver error was [2/1146]: QMYSQL3: Unable to execute query Database error was: Table 'mythconverg.settings' doesn't exist
2008-07-09 23:30:28.298 DB Error (StorageGroup::StorageGroup()): Query was: SELECT DISTINCT dirname FROM storagegroup WHERE groupname = 'DB Backups' AND hostname = 'goofee.no-ip.info' Driver error was [2/1146]: QMYSQL3: Unable to execute query Database error was: Table 'mythconverg.storagegroup' doesn't exist
2008-07-09 23:30:28.301 New DB connection, total: 3 2008-07-09 23:30:28.303 Connected to database 'mythconverg' at host: localhost 2008-07-09 23:30:28.311 SG(DB Backups) Error: Directory value for Default Storage Group is empty. Using hardcoded default value of '/mnt/store' 2008-07-09 23:30:28.331 SG(DB Backups) Error: FindNextDirMostFree: '/mnt/store' does not exist! 2008-07-09 23:30:28.334 Backing up database to file: /tmp/mythconverg--20080709233028.sql 2008-07-09 23:30:28.401 Compressing database backup file. 2008-07-09 23:30:28.458 Database Backup filename: /tmp/mythconverg--20080709233028.sql.gz 2008-07-09 23:30:28.469 Database Backup complete. 2008-07-09 23:30:28.476 DB Error (Clear setting): Query was: DELETE FROM settings WHERE value = 'BackupDBLastRunEnd' AND hostname is NULL; Driver error was [2/1146]: QMYSQL3: Unable to execute query Database error was: Table 'mythconverg.settings' doesn't exist
2008-07-09 23:30:28.479 DB Error (SaveSettingOnHost query failure: ): Query was: INSERT INTO settings (value,data,hostname ) VALUES ( 'BackupDBLastRunEnd', '2008-07-09 23:30:28', NULL ); Driver error was [2/1146]: QMYSQL3: Unable to execute query Database error was: Table 'mythconverg.settings' doesn't exist
2008-07-09 23:30:28.489 No current database version. Auto upgrading 2008-07-09 23:30:28.508 Newest Schema Version : 1214 2008-07-09 23:30:28.545 Inserting MythTV initial database information. 2008-07-09 23:30:28.568 Upgrading to schema version 1112 2008-07-09 23:30:29.129 New DB connection, total: 4 2008-07-09 23:30:29.134 Connected to database 'mythconverg' at host: localhost 2008-07-09 23:30:29.164 Upgrading to schema version 1113 2008-07-09 23:30:29.169 Upgrading to schema version 1114 2008-07-09 23:30:29.176 Upgrading to schema version 1115 2008-07-09 23:30:29.186 Upgrading to schema version 1116 2008-07-09 23:30:29.195 Upgrading to schema version 1117 2008-07-09 23:30:29.207 Upgrading to schema version 1118 2008-07-09 23:30:29.224 Upgrading to schema version 1119 2008-07-09 23:30:29.233 Upgrading to schema version 1120 2008-07-09 23:30:29.243 Upgrading to schema version 1121 2008-07-09 23:30:29.249 Upgrading to schema version 1122 2008-07-09 23:30:29.260 Upgrading to schema version 1123 2008-07-09 23:30:29.281 Upgrading to schema version 1124 2008-07-09 23:30:29.293 Upgrading to schema version 1125 2008-07-09 23:30:29.316 Upgrading to schema version 1126 2008-07-09 23:30:29.330 Upgrading to schema version 1127 2008-07-09 23:30:29.356 Upgrading to schema version 1128 2008-07-09 23:30:29.371 Upgrading to schema version 1129 2008-07-09 23:30:29.395 Upgrading to schema version 1130 2008-07-09 23:30:29.402 Upgrading to schema version 1131 2008-07-09 23:30:29.415 Upgrading to schema version 1132 2008-07-09 23:30:29.428 Upgrading to schema version 1133 2008-07-09 23:30:29.441 Upgrading to schema version 1134 2008-07-09 23:30:29.448 Upgrading to schema version 1135 2008-07-09 23:30:29.467 Upgrading to schema version 1136 2008-07-09 23:30:29.481 Upgrading to schema version 1137 2008-07-09 23:30:29.495 Upgrading to schema version 1138 2008-07-09 23:30:29.503 Upgrading to schema version 1139 2008-07-09 23:30:29.547 Upgrading to schema version 1140 2008-07-09 23:30:29.554 Upgrading to schema version 1141 2008-07-09 23:30:29.575 Upgrading to schema version 1142 2008-07-09 23:30:29.585 Upgrading to schema version 1143 2008-07-09 23:30:29.599 Upgrading to schema version 1144 2008-07-09 23:30:29.606 Upgrading to schema version 1145 2008-07-09 23:30:29.614 Upgrading to schema version 1146 2008-07-09 23:30:29.621 Upgrading to schema version 1147 2008-07-09 23:30:29.643 Upgrading to schema version 1148 2008-07-09 23:30:29.669 Upgrading to schema version 1149 2008-07-09 23:30:29.699 Upgrading to schema version 1150 2008-07-09 23:30:29.705 Upgrading to schema version 1151 2008-07-09 23:30:29.735 Upgrading to schema version 1152 2008-07-09 23:30:29.747 Upgrading to schema version 1153 2008-07-09 23:30:29.770 Upgrading to schema version 1154 2008-07-09 23:30:29.794 Upgrading to schema version 1155 2008-07-09 23:30:29.813 Upgrading to schema version 1156 2008-07-09 23:30:29.829 Upgrading to schema version 1157 2008-07-09 23:30:29.836 Upgrading to schema version 1158 2008-07-09 23:30:29.877 Upgrading to schema version 1159 2008-07-09 23:30:29.925 Upgrading to schema version 1160 2008-07-09 23:30:29.932 Upgrading to schema version 1161 2008-07-09 23:30:29.943 Upgrading to schema version 1162 2008-07-09 23:30:29.952 Upgrading to schema version 1163 2008-07-09 23:30:29.956 Upgrading to schema version 1164 2008-07-09 23:30:29.977 Upgrading to schema version 1165 2008-07-09 23:30:30.003 Upgrading to schema version 1166 2008-07-09 23:30:30.058 Upgrading to schema version 1167 2008-07-09 23:30:30.120 Upgrading to schema version 1168 2008-07-09 23:30:30.138 Upgrading to schema version 1169 2008-07-09 23:30:30.145 Upgrading to schema version 1170 2008-07-09 23:30:30.149 Upgrading to schema version 1171 2008-07-09 23:30:30.204 Upgrading to schema version 1172 2008-07-09 23:30:30.219 Upgrading to schema version 1173 2008-07-09 23:30:30.232 Upgrading to schema version 1174 2008-07-09 23:30:30.239 Upgrading to schema version 1175 2008-07-09 23:30:30.248 Upgrading to schema version 1176 2008-07-09 23:30:30.253 Upgrading to schema version 1177 2008-07-09 23:30:30.266 Upgrading to schema version 1178 2008-07-09 23:30:30.466 Upgrading to schema version 1179 2008-07-09 23:30:30.649 Upgrading to schema version 1180 2008-07-09 23:30:30.671 Upgrading to schema version 1181 2008-07-09 23:30:30.687 Upgrading to schema version 1182 2008-07-09 23:30:30.695 Upgrading to schema version 1183 2008-07-09 23:30:30.708 Upgrading to schema version 1184 2008-07-09 23:30:30.722 Upgrading to schema version 1185 2008-07-09 23:30:30.733 Upgrading to schema version 1186 2008-07-09 23:30:30.746 Upgrading to schema version 1187 2008-07-09 23:30:30.756 Upgrading to schema version 1188 2008-07-09 23:30:30.764 Upgrading to schema version 1189 2008-07-09 23:30:30.778 Upgrading to schema version 1190 2008-07-09 23:30:30.793 Upgrading to schema version 1191 2008-07-09 23:30:30.804 Upgrading to schema version 1192 2008-07-09 23:30:30.819 Upgrading to schema version 1193 2008-07-09 23:30:30.833 Upgrading to schema version 1194 2008-07-09 23:30:30.842 Upgrading to schema version 1195 2008-07-09 23:30:30.849 Upgrading to schema version 1196 2008-07-09 23:30:30.854 Upgrading to schema version 1197 2008-07-09 23:30:30.861 Upgrading to schema version 1198 2008-07-09 23:30:30.867 Upgrading to schema version 1199 2008-07-09 23:30:30.872 Upgrading to schema version 1200 2008-07-09 23:30:30.881 Upgrading to schema version 1201 2008-07-09 23:30:30.886 Upgrading to schema version 1202 2008-07-09 23:30:30.923 Upgrading to schema version 1203 2008-07-09 23:30:30.934 Upgrading to schema version 1204 2008-07-09 23:30:30.943 Upgrading to schema version 1205 2008-07-09 23:30:30.954 Upgrading to schema version 1206 2008-07-09 23:30:30.961 Upgrading to schema version 1207 2008-07-09 23:30:30.982 Upgrading to schema version 1208 2008-07-09 23:30:30.997 Upgrading to schema version 1209 2008-07-09 23:30:31.011 Upgrading to schema version 1210 2008-07-09 23:30:31.154 Upgrading to schema version 1211 2008-07-09 23:30:31.292 Upgrading to schema version 1212 2008-07-09 23:30:31.328 Upgrading to schema version 1213 2008-07-09 23:30:31.339 In 1213 upg 2008-07-09 23:30:31.346 Upgrading to schema version 1214 2008-07-09 23:30:31.362 Database Schema upgrade complete, unlocking. No setting found for this machine's BackendServerIP. Please run setup on this machine and modify the first page of the general settings. 2008-07-10 01:36:34.082 Using runtime prefix = /usr 2008-07-10 01:36:34.115 Empty LocalHostName. 2008-07-10 01:36:34.116 Using localhost value of goofee.no-ip.info 2008-07-10 01:36:34.120 Testing network connectivity to 192.168.0.120 2008-07-10 01:36:34.270 New DB connection, total: 1 2008-07-10 01:36:34.339 Connected to database 'mythconverg' at host: 192.168.0.120 2008-07-10 01:36:34.370 Closing DB connection named 'DBManager0' 2008-07-10 01:36:34.409 Connected to database 'mythconverg' at host: 192.168.0.120 2008-07-10 01:36:34.434 New DB connection, total: 2 2008-07-10 01:36:34.437 Unable to connect to database! 2008-07-10 01:36:34.439 Driver error was [1/2003]: QMYSQL3: Unable to connect Database error was: Can't connect to MySQL server on '192.168.0.120' (111)
QSqlQuery::exec: database not open QSqlQuery::exec: database not open 2008-07-10 01:36:34.496 DB Error (KickDatabase): Query was: SELECT NULL; No error type from QSqlError? Strange... 2008-07-10 01:36:34.548 Database not open while trying to load setting: DBSchemaVer 2008-07-10 01:36:34.553 Current Schema Version: 2008-07-10 01:36:34.556 DataDirectProcessor::FixProgramIDs() -- begin 2008-07-10 01:36:34.559 New DB DataDirect connection 2008-07-10 01:36:34.561 Unable to connect to database! 2008-07-10 01:36:34.562 Driver error was [1/2003]: QMYSQL3: Unable to connect Database error was: Can't connect to MySQL server on '192.168.0.120' (111)
And it caries on like that.
Is my backup screwed even though it restores ok?
Another thing I was just thinking about was when myth.21 first came out my Ubuntu frontend upgraded my database for me. (without asking) I manually restored just the table for my capture card and removed the new weather tables. Everything seemed to work fine after that. Was there other stuff upgraded in the database that could be causing this?
Thanks for your time.
|
|
Top |
|
|
tjc
|
Posted: Thu Jul 10, 2008 6:33 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
goofee wrote: It never went into the infinite loop as it did before but got to upgrading DB schema. It proceded to draw dots across the screen. Success!!! The way it detects the upgrade finishing has some loopholes... goofee wrote: Was there other stuff upgraded in the database that could be causing this?
Probably part of the issue. The DB upgrade by the mythbackend server is driven by schema version IDs in the settings table. The way you recovered left the DB in a mixed state.
Code: select distinct value from settings where value like '%SchemaVer'
will list all the schema version info. You might try setting the appropriate ones of those (Sorry, I don't know which off the top of my head, you'll have to do some research) back and letting it try to redo the schema upgrade. Be warned that it might sick up on changes that have already been made.
|
|
Top |
|
|
ceenvee703
|
Posted: Fri Jul 11, 2008 7:48 am |
|
Joined: Fri Apr 02, 2004 10:08 am
Posts: 1637
Location:
Virginia, USA
|
So, if I change the /home/mythtv/.mythtv/mysql.txt setting to "localhost" instead of the backend IP number _before_ I do my backup/auto-upgrade, I shouldn't have to do what goofee did (i.e. pause the install and edit the file, then proceed with install)?
|
|
Top |
|
|
greywire
|
Posted: Fri Jul 11, 2008 1:14 pm |
|
Joined: Mon Oct 18, 2004 12:22 pm
Posts: 66
Location:
orange county ca
|
goofee wrote: Another thing I was just thinking about was when myth.21 first came out my Ubuntu frontend upgraded my database for me. (without asking) I manually restored just the table for my capture card and removed the new weather tables. Everything seemed to work fine after that. Was there other stuff upgraded in the database that could be causing this? Thanks for your time.
This is exactly what happened to me. I left it going last night because I didnt know how long it should take and this morning it was still printing dots. Now I know why, because I had done what you did with ubuntu and then I had to manually fix some of the tables. Guess it made more changes than that, though.
So what can I do now, to upgrade to 5.5? Do I need to go in and compare my existing schema to see what else was changed, fix them, and try the upgrade again?
or, can I let the new mythtv in ubuntu do its autoupgrade again (which will keep my R5F27 mythbox from running temporarily) and then do the 5.5 upgrade?
It seems like whats happening is that 5.5's upgrade scripts are just getting confused about the partialy upgraded database, so if I either make sure its downgraded OR fully upgraded it should work.
_________________ --
Lead Developer, Trixbox CE.
Fonality, inc.
|
|
Top |
|
|
goofee
|
Posted: Fri Jul 11, 2008 3:56 pm |
|
Joined: Sat Feb 03, 2007 12:52 am
Posts: 187
Location:
Manitoba, Canada
|
What I did was throw in a spare hard drive and install R5F27. I backed up that DB and restored it into my main drive now running R5.5 I then ran mythbackend -v database > backend.log to log all the SQL commands used to upgrade the DB. Tonight I plan to sift trough them and find the ones that alter the DB so I can restore the current backup and bring the DB fully up to date. I'll post my results when I get it.
|
|
Top |
|
|
tjc
|
Posted: Fri Jul 11, 2008 7:50 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
That sounds like a heroic undertaking. I salute your courage and persistence!
|
|
Top |
|
|
goofee
|
Posted: Fri Jul 11, 2008 10:31 pm |
|
Joined: Sat Feb 03, 2007 12:52 am
Posts: 187
Location:
Manitoba, Canada
|
Quote: That sounds like a heroic undertaking. I salute your courage and persistence!
Well it was defiantly more than expected. Might have been easier to take that fresh database and add the necessary stuff for my recordings. But if I didn't want something to tinker with I could have just got a Tivo.
R5F27 DBSchemaVer 1160 (myth .20.2?)
R5.5 DBSchemaVer 1214 (myth .21.?)
I went through the upgrade log and applied it to my current backup and it worked. I when through the whole thing but most commands gave result like "table already present" which would have killed the auto upgrade. I think the biggest ones where the ones that affected the capturecard table cause that's the one I replaced.
I uploaded the modified log to http://www.mts.net/~wfee/backend.log.filtered
It may not work for every one, there are some SELECT statements followed by INSERT statements based on that results. I tried to mark them, hope I got them all. There are three spots where it uses the host name marked by **hostname**, insert your own. I also noticed a few SELECT statements for hardware that I don't have. If it was present it may have gone down a different path.
I connected to the database remotely using MySQL Query Browser, copy and pasted about 10 lines at a time, then executed them one at a time to verify the result. There is probably an easier way but I'm not that great with SQL.
ceenvee703 - I think what did it was changing the bind address in /etc/mysql/my.cnf and restart server. That would affect the server globally and allow any ip to connect.
|
|
Top |
|
|