[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