[mythtv-users] new recordings missing database fields after R5A22
upgrade
Michael T. Dean
mtdean at thirdcontact.com
Wed Oct 26 18:10:01 EDT 2005
Bruce Markey wrote:
> Byron Poland wrote:
>
>> On 10/26/05, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>>
>>> Byron Poland wrote:
>>>
>>>> On 10/26/05, Michael T. Dean <mtdean at thirdcontact.com> 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
More information about the mythtv-users
mailing list