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

[mythtv]

Mike,
I still need to read through your message below a couple of times, but I
got involved in other things and then I found what appears to be the
source of the problem I am seeing.

First, I have moved to the git of the stable version, and all is well
(exhaling).

Part of the problem that I was having was after I edited the cutlist,
the selected video was inverted in the thumbfinder of mytharchive.

I have noticed that other users of cutlist check the value for CUT_START
and CUT_END, but ThumbFinder (e.g., in ThumbFinder::calcFinalDuration)
just assumes that the first is a START, the second is an END,
alternating until the end of the list.

Since I had only a END (no start) and a START (no end) in my markups, I
believe ThumbFinder is getting very confused.

Has the usage of the markup table changed since ThumbFinder was written
in such a way that the assumptions there are no longer valid?


Thanks
Mark


On Sat, 2011-06-25 at 12:58 -0400, Michael T. Dean wrote:
> <Response to your post inline, below, but since it's probably not too 
> important, now, I'm "starting new" up here>
> 
> I just realized that you were the same Mark that added a comment on 
> #9729.  I think the problem you're having--since you're using 
> MythArchive--is actually http://code.mythtv.org/trac/ticket/9389 .  In 
> other words, you just need fixed up Python code for MythArchive.  
> There's some code on #9389, but I don't know my Python (nor 
> MythArchive's existing Python scripts), which is why I passed the ticket 
> off after I fixed what I (mistakenly) thought was causing the 
> problem***.  On the bright side, editing the Python scripts can be done 
> with a packaged install--no need to switch to self-compiled to work on 
> this problem.
> 
> Oh, and FWIW, asking about problems on the -users list (as you did this 
> time) and providing information like you did in the comment on #9729 (so 
> I would have realized you're actually struggling with MythArchive) is 
> the best way to find information about the problem and get information 
> on a) whether it's actually a problem in MythTV or a configuration 
> issue, b) whether a ticket already exists for the issue (so you can 
> watch it for fixes or work on a fix yourself), and c) details of what's 
> wrong, which might help in working around the issue (or fixing it 
> yourself).  Since your comment was on our bug database, it wasn't the 
> right place for discussion, so even if I had noticed that yours was 
> unrelated (and was actually due to a problem reported in a different 
> ticket), I likely wouldn't have responded.  On the -users list, however, 
> I have plenty of room to write long novels explaining way more info than 
> you're looking to get (as I've done here).
> 
> ***At the time I accepted the ticket, I didn't realize that the 
> MythArchive Python scripts were reading the database directly--I assumed 
> it was getting a cut list from mythcommflag --getcutlist.  So, I fixed 
> the output of --getcutlist to be like it was in 0.23 and below, but that 
> didn't fix the problem in MythArchive, since it's using its own code to 
> read the cut list directly from the database (so it needs to be modified 
> to interpret the new format).  Basically, we no longer store the 0 frame 
> or the "last" frame in the cut list.  So, if the first mark is a cut 
> end, we know we cut from the beginning until the mark.  If the last mark 
> is a cut begin, we know we cut from that mark to the end of the 
> recording.  The Python script just needs updated to properly interpret 
> the data (since it's not using the existing code that interprets the data).
> 
> Note, also, that Raymond Wagner has a patch that converts (most or all 
> of) the MythArchive Python scripts to use the Python bindings--which 
> should help prevent this kind of issue in the future.  I'm not sure if 
> that fix will go in before 0.25 is released, but even if not, we should 
> get some fix into 0.24-fixes--as soon as a dev who knows the 
> scripts/Python has a chance to work on it.  Until then, you can easily 
> apply patches yourself.
> 
> 
> On 06/24/2011 11:31 PM, Mark wrote:
> > On Fri, 2011-06-24 at 23:09 -0400, Mark wrote:
> >> 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.
> 
> Yeah, you /should/ get MARK_UPDATED_CUT entries when you use the 
> editor--because you /are/ updating the cut list.  :)
> 
> When the transcoder runs, it starts by removing the MARK_UPDATED_CUT 
> entry.  In unstable/development, though, when it set the new cut list 
> without the MARK_UPDATED_CUT, the undo/redo code added some temporary 
> marks (so it could undo back to the previous--but exactly identical--cut 
> list), which resulted in the undo code adding a new MARK_UPDATED_CUT.  
> Then, when mythtranscode got around to checking if someone else changed 
> the cut list, it saw the MARK_UPDATED_CUT, and exited--even though the 
> mark was put there as a side effect of the transcoder's code to remove 
> the mark.
> 
> > 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?
> 
>  From the mythfrontend --version, you see that you're using "0.24.1" 
> (with some RPM-specific packaging on the end).  That means you're on 
> fixes/0.24 branch, somewhere after 0.24.1 was released.  Specifically, 
> in this case, you're at revision 3657f313ac .
> 
> So, you can find that changeset at ht tps://githu b.com/MythTV /myth 
> tv/com mit/3657f313ac -- *do not* go to that web page (spaces added to 
> obfuscate the link).  Unfortunately, they packaged a revision that 
> corresponded to a /huge/ translation changeset--meaning github's "make 
> it all look pretty" JavaScript will lock up your browser for a long time 
> (could be many minutes) if you go to it (and can lock it up several 
> different times if you leave the tab open after you finally get it 
> displayed).
> 
> So, a /much/ safer way to find out when that was pushed is to use a 
> local copy of the git repo and issue the command:
> 
> git log -1 3657f313ac
> 
> which gives:
> 
> commit 3657f313ac1c57ed0df171130bd914717f0084c3
> Author: Nick Morrott <knowledgejunkie>
> Date:   Mon May 30 01:15:47 2011 -0400
> 
>      Update en_gb MythFrontend, MythArcive and MythGallery translation 
> from Nick
> 
>      Thank you Nick!
> 
>      Closes #9805
> 
>      Signed-off-by: Nicolas Riendeau <nriendeau at mythtv.org>
> 
> meaning you're on a build from May 30.  And you can see the difference 
> between that revision and current 0.24-fixes by getting a copy of the 
> repo and updating to most current (do a git pull if you're not sure if 
> it's current) and issuing:
> 
> git diff 3657f313ac HEAD > ~/diffs
> 
> which shows that there's not a log of difference between your copy and 
> current 0.24-fixes--and, specifically, no differences in the transcoder 
> code.

... snip ...

> 
> 
> Mike