Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

new recordings missing database fields after R5A22 upgrade

  

 
MythTV users RSS feed   Index | Next | Previous | View Threaded


wpoland at gmail

Oct 25, 2005, 9:15 PM

Post #1 of 17 (3456 views)
Permalink
new recordings missing database fields after R5A22 upgrade
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.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


kuphal at dls

Oct 26, 2005, 6:25 AM

Post #2 of 17 (3409 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 7:17 AM

Post #3 of 17 (3419 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Kevin Kuphal <kuphal [at] dls> 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 [at] mythtv
> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 26, 2005, 9:22 AM

Post #4 of 17 (3421 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
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: XXXX," followed by "Newest Schema Version : XXXX," (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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 26, 2005, 9:29 AM

Post #5 of 17 (3411 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
Byron Poland wrote:

>On 10/26/05, Kevin Kuphal <kuphal [at] dls> 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 [at] mythtv
>>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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 10:57 AM

Post #6 of 17 (3407 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> Byron Poland wrote:
>
> >On 10/26/05, Kevin Kuphal <kuphal [at] dls> 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 [at] mythtv
> >>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 [at] mythtv
> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


kuphal at dls

Oct 26, 2005, 11:42 AM

Post #7 of 17 (3411 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
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: XXXX," followed by "Newest Schema Version :
> XXXX," (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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 12:05 PM

Post #8 of 17 (3405 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Kevin Kuphal <kuphal [at] dls> 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: XXXX," followed by "Newest Schema Version :
> > XXXX," (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 [at] mythtv
> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 26, 2005, 12:24 PM

Post #9 of 17 (3415 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 12:29 PM

Post #10 of 17 (3405 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 26, 2005, 12:48 PM

Post #11 of 17 (3412 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
Byron Poland wrote:

>On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 1:09 PM

Post #12 of 17 (3403 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> Byron Poland wrote:
>
> >On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bjm at lvcm

Oct 26, 2005, 2:41 PM

Post #13 of 17 (3424 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
Byron Poland wrote:
> On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> wrote:
>> Byron Poland wrote:
>>
>>> On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 3:09 PM

Post #14 of 17 (3407 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Bruce Markey <bjm [at] lvcm> wrote:
> Byron Poland wrote:
> > On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> >> Byron Poland wrote:
> >>
> >>> On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 26, 2005, 3:10 PM

Post #15 of 17 (3407 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
Bruce Markey wrote:

> Byron Poland wrote:
>
>> On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> wrote:
>>
>>> Byron Poland wrote:
>>>
>>>> On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 26, 2005, 3:26 PM

Post #16 of 17 (3412 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
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 [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wpoland at gmail

Oct 26, 2005, 3:32 PM

Post #17 of 17 (3420 views)
Permalink
Re: new recordings missing database fields after R5A22 upgrade [In reply to]
On 10/26/05, Michael T. Dean <mtdean [at] thirdcontact> 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 [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

Cool.

I appreciate everyone's help.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.