<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 30, 2014 at 6:20 AM, Carl Hunter <span dir="ltr"><<a href="mailto:cdhunter2@yahoo.com" target="_blank">cdhunter2@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/29/2014 7:00 PM, Karl Newman wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This reply ended up in my spam filter for some reason. Anyway, I was<br>
going to suggest that you try to ping the mythtv-dev list. Although it's<br>
possible that the key developer(s) that worked on that code are no<br>
longer with the project. A git-bisect could be helpful here, too, to<br>
identify the exact commit which broke it, but those are a pain with<br>
mythtv because of the database versioning. You'd really need an isolated<br>
system (or chroot?) to test with.<br>
<br>
Karl<br>
<br>
</blockquote>
<br>
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 <a href="http://libmythtv-0.24.so">libmythtv-0.24.so</a>. 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.<br>
<br>
Thanks<br></blockquote></div><br>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: <a href="http://git-scm.com/docs/git-bisect">http://git-scm.com/docs/git-bisect</a> 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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Sincerely,<br><br>Karl<br></div></div>