Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Byron Poland wrote: Since upgrading my backend to Knoppmyth R5A22, all of the recordings I've made are missing the basename, progstart, and progend fields (ie they are blank). this causes jobs like commercial flagging to fail. If I fill in the missing data manually into the tables, things work as expected. Anyone else seeing anything like this? I know very little of mysql. When my commfaging stopped working, I looked at the tables with mysqlcc and saw the missing data. Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Kevin Kuphal [EMAIL PROTECTED] wrote: Byron Poland wrote: Since upgrading my backend to Knoppmyth R5A22, all of the recordings I've made are missing the basename, progstart, and progend fields (ie they are blank). this causes jobs like commercial flagging to fail. If I fill in the missing data manually into the tables, things work as expected. Anyone else seeing anything like this? I know very little of mysql. When my commfaging stopped working, I looked at the tables with mysqlcc and saw the missing data. Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users Thanks for your reply. I already have the basename field, it just doesn't get filled in for new recording. so I just ran the second statement, and it seems to be working now. My progstart and progend fields also weren't working but using the statement you provided as a base I got them to work: UPDATE recorded SET progstart = CONCAT(DATE_FORMAT(starttime, '%Y%m%d%H%i00')); and UPDATE recorded SET progend = CONCAT(DATE_FORMAT(endtime, '%Y%m%d%H%i00')); And they seem to be working again too with a test recording, that now fills the fields correctly. Thanks for your help. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Kevin Kuphal wrote: Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); Correct me if I'm wrong, but isn't it dangerous to run updates this way? In this case, won't it mean that future updates are guaranteed to fail? Since this approach does not update the DBSchemaVer in the database (settings table), next time the backend gets started, it will try to update from the DBSchemaVer it thinks it's using (which is probably the prior version), and will fail because the update contains DDL. If the update contained only DML, it wouldn't make any difference (assuming the DML is idempotent), but DDL changes are never idempotent. Specifically, since the basename column was there, but wasn't properly filled, the DBSchemaVer is probably 1094, so next time mythbackend is started, it will try to update to 1095, and will fail on the ADD COLUMN because the basename column exists (ERROR 1060: Duplicate column name 'basename'), so it will bail out and stop trying to update (i.e. never going to 1099--not even making it to 1096). It seems like the user should shut down mythbackend, then submit: UPDATE settings SET data = '1095' WHERE value = 'DBSchemaVer'; then restart the backend and verify--using the logs--that any requested schema version upgrades succeeded (i.e. Database Schema upgrade complete, unlocking.) or at least that it doesn't say, Current Schema Version: , followed by Newest Schema Version : , (meaning we have the current schema version for the version of Myth in use, so no upgrade was required). (The code in Myth actually deletes the DBSchemaVer setting and then inserts a new one, so if there's some reason that's required, it would be more correct than the UPDATE above.) Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Byron Poland wrote: On 10/26/05, Kevin Kuphal [EMAIL PROTECTED] wrote: Byron Poland wrote: Since upgrading my backend to Knoppmyth R5A22, all of the recordings I've made are missing the basename, progstart, and progend fields (ie they are blank). this causes jobs like commercial flagging to fail. If I fill in the missing data manually into the tables, things work as expected. Anyone else seeing anything like this? I know very little of mysql. When my commfaging stopped working, I looked at the tables with mysqlcc and saw the missing data. Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users Thanks for your reply. I already have the basename field, it just doesn't get filled in for new recording. so I just ran the second statement, and it seems to be working now. My progstart and progend fields also weren't working but using the statement you provided as a base I got them to work: UPDATE recorded SET progstart = CONCAT(DATE_FORMAT(starttime, '%Y%m%d%H%i00')); and UPDATE recorded SET progend = CONCAT(DATE_FORMAT(endtime, '%Y%m%d%H%i00')); And they seem to be working again too with a test recording, that now fills the fields correctly. OK, following on to my previous post--which hinted at the fact that future updates will fail--you're now at schema version 1096--which also contains non-idempotent DDL--so you would need to run: UPDATE settings SET data = '1096' WHERE value = 'DBSchemaVer'; Also, this seems to confirm my suspicions that all future updates are guaranteed to fail if you mess with your database schema incorrectly... And, the bad thing is that I've seen many suggestions like this that totally ignored DBSchemaVer. Therefore, can you post the error messages that exist in your mythbackend log file (if you aren't currently logging, just start up mythbackend before updating DBSchemaVer so you can get them). If you do so, others who see them in their logs will have a reference in the archives. (OK, maybe I'm being too optimistic assuming people will read /both/ their logs /and/ the archives. ;) Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: On 10/26/05, Kevin Kuphal [EMAIL PROTECTED] wrote: Byron Poland wrote: Since upgrading my backend to Knoppmyth R5A22, all of the recordings I've made are missing the basename, progstart, and progend fields (ie they are blank). this causes jobs like commercial flagging to fail. If I fill in the missing data manually into the tables, things work as expected. Anyone else seeing anything like this? I know very little of mysql. When my commfaging stopped working, I looked at the tables with mysqlcc and saw the missing data. Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users Thanks for your reply. I already have the basename field, it just doesn't get filled in for new recording. so I just ran the second statement, and it seems to be working now. My progstart and progend fields also weren't working but using the statement you provided as a base I got them to work: UPDATE recorded SET progstart = CONCAT(DATE_FORMAT(starttime, '%Y%m%d%H%i00')); and UPDATE recorded SET progend = CONCAT(DATE_FORMAT(endtime, '%Y%m%d%H%i00')); And they seem to be working again too with a test recording, that now fills the fields correctly. OK, following on to my previous post--which hinted at the fact that future updates will fail--you're now at schema version 1096--which also contains non-idempotent DDL--so you would need to run: UPDATE settings SET data = '1096' WHERE value = 'DBSchemaVer'; Also, this seems to confirm my suspicions that all future updates are guaranteed to fail if you mess with your database schema incorrectly... And, the bad thing is that I've seen many suggestions like this that totally ignored DBSchemaVer. Therefore, can you post the error messages that exist in your mythbackend log file (if you aren't currently logging, just start up mythbackend before updating DBSchemaVer so you can get them). If you do so, others who see them in their logs will have a reference in the archives. (OK, maybe I'm being too optimistic assuming people will read /both/ their logs /and/ the archives. ;) Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users You've totally lost me for the most part. (Like I said I know very little of mysql). I'll check my backend log on a restart.. and post anything related to DBSchemaVer. How was my DB supposed to be updated in the first place? I'm not home now, but will read this thread a few more times and see if I can put it together, and post some relevent sections of my backend log. If I didn't already have so many recordings that I haven't watched, and a hand made qam channel lineup I'd consider wiping it clean... Also I have the mysql db dump from when I backed it ub before the knoppmyth upgrade. Perhaps I can delete the newer recordings, to get them off the drive, and then re-instate the backup and do what ever update I was supposed to do in the beginning. Well I'll check the logs first and post back. I appreciate the help, hopefully this thread becomes useful to others. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Michael T. Dean wrote: Kevin Kuphal wrote: Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); Correct me if I'm wrong, but isn't it dangerous to run updates this way? In this case, won't it mean that future updates are guaranteed to fail? Since this approach does not update the DBSchemaVer in the database (settings table), next time the backend gets started, it will try to update from the DBSchemaVer it thinks it's using (which is probably the prior version), and will fail because the update contains DDL. If the update contained only DML, it wouldn't make any difference (assuming the DML is idempotent), but DDL changes are never idempotent. Specifically, since the basename column was there, but wasn't properly filled, the DBSchemaVer is probably 1094, so next time mythbackend is started, it will try to update to 1095, and will fail on the ADD COLUMN because the basename column exists (ERROR 1060: Duplicate column name 'basename'), so it will bail out and stop trying to update (i.e. never going to 1099--not even making it to 1096). It seems like the user should shut down mythbackend, then submit: UPDATE settings SET data = '1095' WHERE value = 'DBSchemaVer'; then restart the backend and verify--using the logs--that any requested schema version upgrades succeeded (i.e. Database Schema upgrade complete, unlocking.) or at least that it doesn't say, Current Schema Version: , followed by Newest Schema Version : , (meaning we have the current schema version for the version of Myth in use, so no upgrade was required). depends. I ran into this very problem moving up SVN versions and my DBSchemaVer was well beyond what was necessary for that update to trigger but it never did so I was running into the same problem. I think there is something broken with that particular update but I can't see anything wrong with it from looking at the code. I think you will find that his DBSchemaVer is correct and the statement didn't execute. I wouldn't recommend anyone setting their DBSchemaVer manually. Kevin ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Kevin Kuphal [EMAIL PROTECTED] wrote: Michael T. Dean wrote: Kevin Kuphal wrote: Sounds like a DB update was missed. If you do not have the basename field in your DB, execute this SQL statement against it: ALTER TABLE recorded ADD COLUMN basename varchar(128) NOT NULL DEFAULT; and then, once it is in your database, run this: UPDATE recorded SET basename = CONCAT(chanid, '_', DATE_FORMAT(starttime, '%Y%m%d%H%i00'), '_', DATE_FORMAT(endtime, '%Y%m%d%H%i00'), '.nuv'); Correct me if I'm wrong, but isn't it dangerous to run updates this way? In this case, won't it mean that future updates are guaranteed to fail? Since this approach does not update the DBSchemaVer in the database (settings table), next time the backend gets started, it will try to update from the DBSchemaVer it thinks it's using (which is probably the prior version), and will fail because the update contains DDL. If the update contained only DML, it wouldn't make any difference (assuming the DML is idempotent), but DDL changes are never idempotent. Specifically, since the basename column was there, but wasn't properly filled, the DBSchemaVer is probably 1094, so next time mythbackend is started, it will try to update to 1095, and will fail on the ADD COLUMN because the basename column exists (ERROR 1060: Duplicate column name 'basename'), so it will bail out and stop trying to update (i.e. never going to 1099--not even making it to 1096). It seems like the user should shut down mythbackend, then submit: UPDATE settings SET data = '1095' WHERE value = 'DBSchemaVer'; then restart the backend and verify--using the logs--that any requested schema version upgrades succeeded (i.e. Database Schema upgrade complete, unlocking.) or at least that it doesn't say, Current Schema Version: , followed by Newest Schema Version : , (meaning we have the current schema version for the version of Myth in use, so no upgrade was required). depends. I ran into this very problem moving up SVN versions and my DBSchemaVer was well beyond what was necessary for that update to trigger but it never did so I was running into the same problem. I think there is something broken with that particular update but I can't see anything wrong with it from looking at the code. I think you will find that his DBSchemaVer is correct and the statement didn't execute. I wouldn't recommend anyone setting their DBSchemaVer manually. Kevin ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. no errors... it does do this on every start of the backend though. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. no errors... it does do this on every start of the backend though. What does SELECT data FROM settings WHERE value = 'DBSchemaVer'; give? Thanks, Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. no errors... it does do this on every start of the backend though. What does SELECT data FROM settings WHERE value = 'DBSchemaVer'; give? Thanks, Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users mysql SELECT data FROM settings WHERE value = 'DBSchemaVer'; +--+ | data | +--+ | 1099 | +--+ 1 row in set (0.00 sec) ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. no errors... it does do this on every start of the backend though. What does SELECT data FROM settings WHERE value = 'DBSchemaVer'; give? mysql SELECT data FROM settings WHERE value = 'DBSchemaVer'; +--+ | data | +--+ | 1099 | +--+ 1 row in set (0.00 sec) And it's still trying to upgrade the database on every backend restart? (You keep seeing the, Setting Lock for Database Schema upgrade, message?) Were there lines: Current Schema Version: 109X Newest Schema Version : 1099 above the, Setting lock, message in the log? Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. no errors... it does do this on every start of the backend though. What does SELECT data FROM settings WHERE value = 'DBSchemaVer'; give? mysql SELECT data FROM settings WHERE value = 'DBSchemaVer'; +--+ | data | +--+ | 1099 | +--+ 1 row in set (0.00 sec) And it's still trying to upgrade the database on every backend restart? (You keep seeing the, Setting Lock for Database Schema upgrade, message?) Were there lines: Current Schema Version: 109X Newest Schema Version : 1099 above the, Setting lock, message in the log? Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users No lines like that. the only thing mentioning the Schema was the messages I posted. full start up logs are below. I just restarted the backend, and ran the mysql statement from above, and the schema version still reports as 1099 2005-10-26 16:07:36.072 Using runtime prefix = /usr QSettings::sync: filename is null/empty 2005-10-26 16:07:36.104 New DB connection, total: 1 2005-10-26 16:07:36.115 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 16:07:36.129 New DB connection, total: 2 2005-10-26 16:07:36.134 Database Schema upgrade complete, unlocking. Starting up as the master server. 2005-10-26 16:07:36.290 mythbackend: MythBackend started as master server 2005-10-26 16:07:36.303 DVB#0 Using DVB card 0, with frontend pcHDTV HD3000 HDTV. QSettings::sync: filename is null/empty 2005-10-26 16:07:36.317 New DB connection, total: 3 2005-10-26 16:07:37.466 DVB#1 Using DVB card 1, with frontend Nextwave nxt2002 VSB/QAM frontend. QSettings::sync: filename is null/empty 2005-10-26 16:07:37.935 New DB scheduler connection 2005-10-26 16:07:37.952 mythbackend version: 0.19.20050712-1 www.mythtv.org 2005-10-26 16:07:37.957 Enabled verbose msgs : important general 2005-10-26 16:07:37.963 AutoExpire: Found 3 recorders w/max rate of 349 MiB/min 2005-10-26 16:07:37.970 AutoExpire: space: 3.7 GB w/freq: 5 min 2005-10-26 16:07:38.365 adding: piper.tube013.org as a slave backend server 2005-10-26 16:07:38.372 adding: glide as a slave backend server 2005-10-26 16:07:39.952 Reschedule requested for id 0. 2005-10-26 16:07:39.957 Reschedule requested for id 0. 2005-10-26 16:07:39.961 Reschedule requested for id -1. 2005-10-26 16:07:40.235 Scheduled 51 items in 0.3 = 0.16 match + 0.12 place 2005-10-26 16:07:40.246 scheduler: Scheduled items 2005-10-26 16:07:40.257 Seem to be woken up by USER 2005-10-26 16:07:43.375 AutoExpire: Found 3 recorders w/max rate of 349 MiB/min 2005-10-26 16:07:43.386 AutoExpire: space: 3.7 GB w/freq: 5 min 2005-10-26 16:07:47.953 mythbackend: Running housekeeping thread 2005-10-26 16:07:48.406 AutoExpire: Found 3 recorders w/max rate of 349 MiB/min 2005-10-26 16:07:48.415 AutoExpire: space: 3.7 GB w/freq: 5 min ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty User doesn't have ~/.qt dir? Missing Current Schema Version: message as of changeset 7260... 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. ... mysql SELECT data FROM settings WHERE value = 'DBSchemaVer'; +--+ | data | +--+ | 1099 | +--+ ... 2005-10-26 16:07:36.115 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. Most likely you are inadvertently running an older version of mythbackend. This would explain why you don't see the version message, why it thinks the schema version number doesn't match and why the basename field is not being filled in. If there is more than one machine involved, check that you have installed the same version on all machines. Run locate mythbackend to see if there is more than one executable. If you start the backend from a script, check the path in the script and if from the commandline, check which mythbackend. -- bjm ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Bruce Markey [EMAIL PROTECTED] wrote: Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty User doesn't have ~/.qt dir? Missing Current Schema Version: message as of changeset 7260... 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. ... mysql SELECT data FROM settings WHERE value = 'DBSchemaVer'; +--+ | data | +--+ | 1099 | +--+ ... 2005-10-26 16:07:36.115 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. Most likely you are inadvertently running an older version of mythbackend. This would explain why you don't see the version message, why it thinks the schema version number doesn't match and why the basename field is not being filled in. If there is more than one machine involved, check that you have installed the same version on all machines. Run locate mythbackend to see if there is more than one executable. If you start the backend from a script, check the path in the script and if from the commandline, check which mythbackend. -- bjm ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users This might be it. I had to compile from SVN to get the protocol on my frontend (ubuntu) (Which I also use as a slave backend to commflag and transcode) to match up with the backend (knoppmyth R5A22) so they very well could be different versions. I just located the source for the knoppmyth version, and am compiling it now. Will just equalizing all the version fix any problems or do I have prolems that need to be addressed? I may start my upgrade over again, I'll just loose some of my newer recordings which aren't too many in number. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Bruce Markey wrote: Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: Here is the relevant part of my backend log on on startup: 2005-10-26 15:02:15.804 Using runtime prefix = /usr QSettings::sync: filename is null/empty User doesn't have ~/.qt dir? Or is running from an environment without a HOME, so is lacking permissions on /.qt? If so, the improper env may also give PATH issues, which may have an impact on the rest... Missing Current Schema Version: message as of changeset 7260... Thank you I couldn't figure out how he could have gotten the Setting lock message without the Current Schema Version because it wouldn't be possible with the /current/ code. 2005-10-26 15:02:15.953 New DB connection, total: 1 2005-10-26 15:02:15.991 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. QSettings::sync: filename is null/empty 2005-10-26 15:02:16.005 New DB connection, total: 2 2005-10-26 15:02:16.013 Database Schema upgrade complete, unlocking. ... mysql SELECT data FROM settings WHERE value = 'DBSchemaVer'; +--+ | data | +--+ | 1099 | +--+ ... 2005-10-26 16:07:36.115 Setting Lock for Database Schema upgrade. If you see a long pause here it means the Schema is already locked and is being upgraded by another Myth process. Most likely you are inadvertently running an older version of mythbackend. This would explain why you don't see the version message, why it thinks the schema version number doesn't match and why the basename field is not being filled in. If there is more than one machine involved, check that you have installed the same version on all machines. Run locate mythbackend to see if there is more than one executable. If you start the backend from a script, check the path in the script and if from the commandline, check which mythbackend. And I couldn't figure out why Myth would attempt an upgrade if his DBSchemaVer is 1099--since there's no 1100, yet. But, 1094 != 1099, and upgrade succeeds because no SQL is executed and doUpgradeTVDatabaseSchema( ) returns true. I never would have thought of multiple different versions of mythbackend... So, basically, the mythbackend he's running--and that's creating the logs--is SVN rev 7259 or less (because there's no Current Schema Version) and not 7429 or above (which expects DBSchemaVer 1099). So, at some time he ran a newer version of mythbackend (rev 7429 or above) that upgraded his schema and is now running an older version. This would also explain why his basename and progstart/progend columns are not being set--because they didn't exist in that old version. And, by running the SQL--to update basename, progstart, and progend for all the existing recordings--it made it look as if it fixed the problem, when, in fact, it just fixed the existing recordings, and all new recordings will continue to have problems because they won't have values for these columns because the old version of mythbackend won't set them. I'm so glad you chimed in. I don't think I ever would have gotten there on my own and it's been driving me crazy all afternoon. Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
Byron Poland wrote: I had to compile from SVN to get the protocol on my frontend (ubuntu) (Which I also use as a slave backend to commflag and transcode) to match up with the backend (knoppmyth R5A22) so they very well could be different versions. I just located the source for the knoppmyth version, and am compiling it now. Will just equalizing all the version fix any problems or do I have prolems that need to be addressed? I may start my upgrade over again, I'll just loose some of my newer recordings which aren't too many in number. According to the changelog ( http://www.mysettopbox.tv/CHANGELOG.txt ), R5A22 is using MythTV 0.18.2svn, which is probably the current SVN version of 0.18-fixes? http://svn.mythtv.org/trac/browser/branches/release-0-18-fixes You'll have to get more info from some KnoppMyth experts, though. If it is 0.18-fixes, it's expecting DBSchemaVer 1083 and you have 1099. Between the two have been a lot of changes, including a bunch of DDL--dropped tables, added tables, and added columns. Therefore, you're probably better off starting over from your pre-upgrade backup or just upgrading to current SVN... Most things might work OK with the older version, but I wouldn't risk it. If you start over, you can import the new recordings with myth.rebuilddatabase.pl. Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] new recordings missing database fields after R5A22 upgrade
On 10/26/05, Michael T. Dean [EMAIL PROTECTED] wrote: Byron Poland wrote: I had to compile from SVN to get the protocol on my frontend (ubuntu) (Which I also use as a slave backend to commflag and transcode) to match up with the backend (knoppmyth R5A22) so they very well could be different versions. I just located the source for the knoppmyth version, and am compiling it now. Will just equalizing all the version fix any problems or do I have prolems that need to be addressed? I may start my upgrade over again, I'll just loose some of my newer recordings which aren't too many in number. According to the changelog ( http://www.mysettopbox.tv/CHANGELOG.txt ), R5A22 is using MythTV 0.18.2svn, which is probably the current SVN version of 0.18-fixes? http://svn.mythtv.org/trac/browser/branches/release-0-18-fixes You'll have to get more info from some KnoppMyth experts, though. If it is 0.18-fixes, it's expecting DBSchemaVer 1083 and you have 1099. Between the two have been a lot of changes, including a bunch of DDL--dropped tables, added tables, and added columns. Therefore, you're probably better off starting over from your pre-upgrade backup or just upgrading to current SVN... Most things might work OK with the older version, but I wouldn't risk it. If you start over, you can import the new recordings with myth.rebuilddatabase.pl. Mike ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users Cool. I appreciate everyone's help. ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
