[mythtv-users] DB Schema update 1261: broken duplicate detection with historic non-DD data

Michael T. Dean mtdean at thirdcontact.com
Wed Apr 22 02:25:11 UTC 2015


On 04/21/2015 09:01 PM, Nick Morrott wrote:
> On 21 April 2015 at 14:43, Michael T. Dean wrote:
>> On 04/21/2015 09:37 AM, Michael T. Dean wrote:
>>> So is there some way you corrupted your database and removed that setting?
>>> I.e. if you don't properly restore the database--and do something broken,
>>> like restoring only certain tables (where doing so is not only broken, but
>>> out-right dangerous if the database version isn't correct/up-to-date) to
>>> "clean up" the database--you could end up running that code again, even
>>> though it was already run in 2007.  Similarly, if you "cleaned up" the
>>> database by removing old settings values that you thought you didn't need,
>>> you could end up running that code again.
> Further investigation this evening, digging in the code and re-running
> the DB upgrade from 0.21-fixes seems to have revealed the problem.
>
> Like others faced with the prospect of an intermediate upgrade before
> being able to install 0.27, I used a VM host (running Debian Squeeze
> and MythTV 0.24 in this case) to speed things along.
>
> The VM host had a different hostname to that configured in the
> database for the system being upgraded, so I opted to use the
> <LocalHostName>  option in config.xml to "correct" the hostname prior
> to the upgrade.
>
> My error was that I quickly checked my 0.27 install for the location
> of the config option (my old config.xml did not contain any hints
> about it - maybe I removed it years ago or maybe it was never added?).
> Only the format of config.xml was changed after 0.24. And you can
> guess the rest...
>
> As a result of the erroneous LocalHostName override, mythtv-setup
> found an empty LocaHostName and defaulted to the hostname of the VM,
> which obviously didn't contain a valid setting for
> MythFillFixProgramIDsHasRunOnce, so the test in the 1261 schema
> upgrade failed and the programid updates were run.

The MythFillFixProgramIDsHasRunOnce was supposed to be a global setting, 
so should not have had any host name associated with it.

> I'm wondering why this particular setting is associated with a given
> hostname, as it would seem to me to be something that makes more sense
> on an installation-wide basis

Exactly.

> , rather than per-host. It clearly caught
> me out though and thankfully was very easy to reverse once I'd worked
> out what was going on.

So in your pre-upgrade backup, do you have a hostname associated with 
that setting?  Hmmm.  Looking in mine, I have 3 copies of the setting, 
one for each of my hosts...???!!!

So, it seems that when the code that inserted that setting back in the 
0.20-fixes days was written, the author didn't realize that 
MythCoreContext::SaveSetting() writes a setting for the current host and 
that creating a global setting requires calling 
MythCoreContext::SaveSettingOnHost() and passing null for the host name.

So, the broken code no longer exists, but this problem should never have 
occurred on your system--and is not your fault.  We should be able to 
upgrade the database properly even from a new host name.

I (where "I" may mean, "whoever I can convince to push the change for me 
since I don't have a working dev system and am unlikely to be able to 
get a chance to set one up soon") would accept a patch which changes the 
line in the 1260 DB update in dbcheck.cpp that uses GetNumSetting() to 
one that does its own query:

SELECT COALESCE(SUM(ABS(data)), 0)
   FROM settings
  WHERE value = 'MythFillFixProgramIDsHasRunOnce';

(ideally with a comment saying that the setting was supposed to be 
global but was accidentally made host-specific, so we're looking for a 
non-zero value on any host/hosts).  You could use one of the existing DB 
queries from dbcheck.cpp as a template for how to run a query in a DB 
update.

Anyway, thanks for digging in and figuring out what's happening.  I 
really don't want that to cause any problems for anyone who will upgrade 
from an old version, so it's good to find the why rather than just 
fixing the data and forgetting about it.

> My apologies and thanks to sphery, and to the list for the unwarranted
> noise in this case.

Again, thank you for identifying a problem and its root cause.  Turns 
out you had a noise warrant after all.  :)

Mike


More information about the mythtv-users mailing list