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
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
