[mythtv-users] mythcommflag not working

Karl Newman newmank1 at asme.org
Thu Oct 2 22:27:51 UTC 2014


On Tue, Sep 30, 2014 at 6:20 AM, Carl Hunter <cdhunter2 at yahoo.com> wrote:

> On 9/29/2014 7:00 PM, Karl Newman wrote:
>
>> This reply ended up in my spam filter for some reason. Anyway, I was
>> going to suggest that you try to ping the mythtv-dev list. Although it's
>> possible that the key developer(s) that worked on that code are no
>> longer with the project. A git-bisect could be helpful here, too, to
>> identify the exact commit which broke it, but those are a pain with
>> mythtv because of the database versioning. You'd really need an isolated
>> system (or chroot?) to test with.
>>
>> Karl
>>
>>
> I do have an isolated system running Mythbuntu 11.10 with 0.24 installed.
> I can compile on it too.  I was thinking of stepping through the git
> commits until it broke.  I think I can compile everything but only use the
> new mythcommflag and libmythtv-0.24.so.  Could someone correct me if I'm
> wrong?  I'm still learning all the git commands too so I'll take a look at
> git-bisect.
>
> Thanks
>

Ugh, this was in my spam filter again. Apparently it's some breakage from
yahoo that mailing lists are expected to "fix". Anyway. If you're set up to
compile on that system, then just checkout the git source for v0.25
(assuming that one is actually bad). Full documentation for git bisect is
here: http://git-scm.com/docs/git-bisect but basically, starting from
v0.25, do a 'git bisect start', then 'git bisect bad' and 'git bisect good
v0.24.2'. That will then checkout a revision halfway between the good and
bad marked revisions. Then compile and test it. If it's still good, mark it
with 'git bisect good' and if not, then 'git bisect bad'. Note that you'll
need to restore a database backup after every 'git bisect bad' because that
moves to an earlier revision which may be incompatible with your (upgraded)
database. If you encounter one that won't compile or run, you can mark it
with 'git bisect skip', which will move to the next revision. Once you've
done this maybe 15(?) times, it should be able to name the bad commit,
which can then get closer inspection.

I fear that after all this you may find that the problem is a monster
ffmpeg import commit which will be impossible to pinpoint where the
breakage is, but if you're willing to try this, I would be very grateful.
I'm also willing to test a patch (and possibly help to put a patch together
from commits) against 0.27 once you get to that point.

Sincerely,

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20141002/05ea79c7/attachment.html>


More information about the mythtv-users mailing list