<br><br><div class="gmail_quote">On Mon, Mar 28, 2011 at 5:18 PM, Kenni Lund <span dir="ltr"><<a href="mailto:kenni@kelu.dk" target="_blank">kenni@kelu.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br>
</div><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">Another thing to try, which would help a lot, is to figure out what<br>
commit introduced the issue in MythTV. If it was introduced at some<br>
point in 0.24-fixes, then the faulty commit can be identified quite<br>
easily with the help of "git bisect". The following actions would need<br>
to be performed:<br></blockquote>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
1. Checkout MythTV at the first git commit in 0.24-fixes (~november<br>
2010), compile it and see if the problem exists in this version. If it<br>
DOESN'T exist in this version, we now know that the issue was<br>
introduced in 0.24-fixes and we can continue with git bisect to<br>
identify the commit.<br></blockquote></blockquote><div><br>I may be wrong, but I believe the development group was still on subversion in November. I do have a tree that I checked out on 11/27 (rev 27361) that I can start with. If that doesn't fix the problem, I'll move backwards in svn trunk.<br>
<br>If I remember messages from Mr. Dean, I can move freely between .024-fixes without worry of my database. If I have to move further back than that, I think I will stop. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
2. Tell git that we want to perform a git bisect, something like:<br>
git bisect start<br>
git bisect bad $latest_0.24-fixes_git_revision_which_has_the_issue<br>
git bisect good $the_initial_0.24-fixes_git_revision_which_DOESNT_have_the_issue<br><br>
3. Git now performs a checkout of a revision in between the two<br>
revisions. Compile it and see if the problem exists or not.<br><br>
4. Depending on the test results, give git feedback on the tested revision:<br>
git bisect good<br>
- or -<br>
git bisect bad<br><br>
Git will checkout a new version to test; test it, give feedback, etc.<br>
In the end, git will spit out the commit which introduced the issue -<br>
which should be the code that needs fixing.<br></blockquote>
</blockquote><div><br>If I get into the git tree, I will follow your suggestions here. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
But take care when judging whether a given revision is good or bad -<br>
one wrong answer will identify the wrong commit in the end, so make<br>
sure it's the same issue you're tracking during the testing (other<br>
things, like damaged frames, can also cause "short pauses" in<br>
playback, so make sure to keep an eye on the logs).<br></blockquote></blockquote><div><br>I will heed your advice. Probably run each version several days. Depends on WAF, but she is pretty understanding, realizing that it is one of my hobbies (as long as I don't destroy the library). <br>
</div><br></div>Thanks for the ideas.<br><br>-- Ken E.<br>