[mythtv-users] Mythbuntu mythtv-database wants to erase my database.

[Michael T. Dean]

On 06/05/2009 07:36 PM, Bill Williamson wrote:
> On Sat, Jun 6, 2009 at 7:52 AM, Robert McNamara wrote:
>   
>> On Fri, Jun 5, 2009 at 2:49 PM, Mike LaPlante wrote:
>>> Should my schema have changed since this wasn't a major release update
>>> just a fixes version?
>> No.  Schema and protocol will never change in official copies of -fixes.
>>  It's one of the "guarantees" in staying with the stable branch.  Using
>> alternate or unofficial sources of patches or packages may break or alter
>> the schema, however, YMMV.  If these are all from mythbuntu repositories,
>> you are fine.
> Is this actaully true?
>   

That's the plan when the real world doesn't get in the way.

> Wasn't there a protocol change from 30 to 31 in the .20 fixes branch?

Yes.  0.20 was released with a major bug that required a protocol change 
to fix it.  So, since the -fixes branch is the stable branch (and 
receives bug fixes), that change was put into 0.20-fixes.  I think Bruce 
Markey summed up the reasoning behind it pretty well at: 
http://www.gossamer-threads.com/lists/mythtv/dev/226499#226499

Of course, 0.20 was branched on Sep 11, 2006 and the change went in on 
Sept 24, 2006.  So, you can think of 0.20 as the release candidate and 
post-Sep-24 0.20-fixes as the release.  :)  (Anyone who's used MythTV 
for a little while knows that you /never/ use the release tarballs.)

>  There
> was also a fairly major schema change to do with mythmusic, which resulted
> in the upnp media server serving music files from an old table structure
> (and thus never updating)...

I don't know what happened here, but I do know that the only times we've 
ever had schema changes in -fixes were occasions where the changes were 
required to fix pretty major bugs (and, in some cases, several schema 
changes--all of the schema changes to that date from trunk--had to be 
backported because of the sequential nature of the DB update procedure).

I'm guessing, though, in the case you mentioned, what actually happened 
was that the MythMusic schema was completely changed in post-<some 
version> trunk--I'm pretty sure it was post-0.20 (so I'm just going with 
that even though I don't feel like looking it up).  Likewise, the UPnP 
code in trunk was completely rewritten.  Then, the UPnP support in the 
released version/-fixes completely broke.  (I don't know exactly what 
happened, but it mostly worked at release, but by the time 0.20.2 came 
around, it wasn't working with devices--and not due to changes to the 
MythTV code.)  Since the UPnP stack in -fixes was basically completely 
broken, the dev working on that part of the code figured that 
backporting the UPnP code from trunk to get a partially-working UPnP 
system would be better than leaving the completely-broken UPnP in 
-fixes.  So, I'm guessing that the backported UPnP was expecting a 
different MythMusic schema and didn't play well with it--but was no 
worse than the completely broken UPnP code it replaced.

However, anytime there's a protocol or schema update in -fixes, it's 
always done in such a way as to ensure a clean upgrade from -fixes to 
the next-released version will be possible without any manual 
intervention (assuming a properly configured database/database 
server--where that disclaimer will likely make more sense when 0.22 is 
released).

Mike