[mythtv-users] How best to move to git bleeding edge from fedora rpm

[mythtv]

On Fri, 2011-06-24 at 23:09 -0400, mythtv wrote:
snip...
> 
> Actually, that one fixes a bug that can not possibly exist in 
> 0.24-fixes.  We don't have undo/redo support in 0.24-fixes--it went
> into 
> unstable shortly after 0.24 was released.  If you look at the change in 
> that commit, I simply commented out one line of code--that doesn't even 
> exist in 0.24's deletemap.cpp.
> 
> The change:
> https://github.com/MythTV/mythtv/commit/e4be111e
> 
> The DeleteMap::SetMap() function in 0.24-fixes:
> https://github.com/MythTV/mythtv/blob/fixes%
> 2F0.24/mythtv/libs/libmythtv/deletemap.cpp#L580
> 
> So, that means if you're getting failures on long runs of the
> transcoder 
> with 0.24-fixes, they're caused by something else.  We just need to 
> figure out why your transcodes are failing...
> 

Hmmmm.
The error you described sounded so much like what I was seeing.
I was getting MARK_UPDATED_CUT entries in my recordedmarkups table when
I used the cutlist editor.  I had thought that that was part of the
undo/redo support, but I have not really figured that out yet, I guess.


I am using a rpm version right now
rpm -q -a | grep mythtv 
gives
mythtv-0.24.1-2.fc14.i686

mythfrontend --version gives
MythTV Version   : 0.24.1-2.fc14 (3657f313ac)

I do not know how the rpms relate to the git branches, and I do not have
source for the rpm.  Do you know where I can find the source associated
with this distribution?




> > http://www.mythtv.org/wiki/Backend_migration  .
> >
> > So there have been no changes to the mythconverg schema between 24.1
> and
> > the master?
> 
> Actually, there have been /many/ changes.  0.24-fixes is schema version 
> 1264 and master is currently at 1277.
> 
> > I will backup the database anyway just in case.  I like to play with
> > a safety net under me.
> >
> 
> Always a good idea.
> 
> However, since upgrading to unstable/development won't fix the issue 
> you're seeing, perhaps you could post some logs and we might be able to 
> figure out what's causing the problem--and save your having to risk
> your 
> TV on unstable code.  :)
> 
> Mike
> 
> 

So the code is smart enough to recognize the schema version of the
database and migrate it forward to the current version.  Cool!

Mark