[mythtv-users] How best to move to git bleeding edge from fedora rpm
mythtv
mythtv at sladenfamily.com
Tue Jun 28 21:17:28 UTC 2011
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
More information about the mythtv-users
mailing list