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

Michael T. Dean mtdean at thirdcontact.com
Sat Jun 25 01:58:44 UTC 2011


On 06/24/2011 09:40 PM, Mark wrote:
> Hi Mike,
> Really appreciate the fix.
>
> >On 06/24/2011 08:55 PM, Mark wrote:
> >>  I would like to transform my myth box from a rpm based system to a
> >>  git based system.
> >>
> >>  mdean made a change recently that I would like to pick up.
> >
> >  Out of curiosity, which change are you looking for?  Is it one on
> >  master that's not in -fixes?  If so, there were a couple of fixes
> >  I've considered backporting, but haven't decided it's worthwhile,
> >  yet.  If someone was looking for one of them, though...
>
> It was
> e4be111e sphery Prevent transcode failures due to false "updated cut list"
>
> I saw it in master, but did not see it in fixes.
> I am not sure how typical of a user I am, but I would find it
> helpful. 
> The analysis is correct, I was transcoding on a relatively slow box
> (reduced power consumption) and a relatively long recording.

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...

> 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



More information about the mythtv-users mailing list