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

[Michael T. Dean]

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

>>> 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.  :
> So the code is smart enough to recognize the schema version of the
> database and migrate it forward to the current version.  Cool!

Yes.  When upgrading, you only have to worry about 2 things:

1)  Manually make a database backup /before/ upgrading so that you can 
go back if things don't work (i.e. if you get an unstable version of 
unstable/development code) since the only way to downgrade is to restore 
a pre-upgrade backup of the database.  Even though MythTV will 
automatically back up your database before upgrading the schema (unless 
you've unwisely checked the box for "Disable automatic database backup" 
that tells it not to), I wouldn't rely on that backup to succeed (and I 
wrote the code that creates that backup), so create one before hand, anyway.

2) Make a decision /very/ quickly about whether to stay on the upgraded 
version.  If you wait until after your system has recorded some new 
shows and then decide to downgrade to the version you were on, when you 
restore the pre-upgrade backup, it will lack information on the new 
recordings--meaning you'd have to stick them in MythVideo and then let 
MythTV re-record them on rerun.  If you wait longer than just a few 
recordings, having 10 episodes of a show in MythTV's Watch Recordings 
and 5 episodes in MythVideo can be somewhat confusing.


Mike