[mythtv-users] Mythbuntu mythtv-database wants to erase my database.
Michael T. Dean
mtdean at thirdcontact.com
Sat Jun 6 00:09:34 UTC 2009
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:
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.)
> 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
More information about the mythtv-users