View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 35 posts ] 
Go to page 1, 2, 3  Next

Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Tue Jul 08, 2008 2:16 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Jul 08, 2008 2:30 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Jul 08, 2008 7:11 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Wed Jul 09, 2008 12:01 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Wed Jul 09, 2008 6:21 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Wed Jul 09, 2008 7:55 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Wed Jul 09, 2008 8:26 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Wed Jul 09, 2008 10:58 pm 
Offline
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.... :oops:

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
 Profile  
 
 Post subject:
PostPosted: Thu Jul 10, 2008 5:52 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Thu Jul 10, 2008 6:33 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Fri Jul 11, 2008 7:48 am 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Fri Jul 11, 2008 1:14 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Fri Jul 11, 2008 3:56 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Fri Jul 11, 2008 7:50 pm 
Offline
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! :-D


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 11, 2008 10:31 pm 
Offline
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
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ] 
Go to page 1, 2, 3  Next



All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu