<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 03/18/2013 01:07 PM, Peter Bennett
(cats22) wrote:<br>
</div>
<blockquote cite="mid:514749C7.4000608@comcast.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 03/17/2013 11:55 PM, Jim Stichnoth
wrote:<br>
</div>
<blockquote
cite="mid:CAF5-JozJOq+TMOaHSjZg2M1cTwEdbzUs-Awcn5AY4wT-oVXZfg@mail.gmail.com"
type="cite">
<div dir="ltr">On Sat, Mar 16, 2013 at 8:32 AM, Peter Bennett
(cats22) <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cats22@comcast.net" target="_blank">cats22@comcast.net</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I
recently upgraded from
mythtv_0.26.0+fixes.20130131.28144cd to<br>
mythtv_0.26.0+fixes.20130308.77259c5.<br>
<br>
During playback now I find that jump forward 1 minute
and jump back 10<br>
seconds (left and right arrow) do not work well.
Sometimes after<br>
pressing left or right arrow, the playback freezes for 5
or 10 seconds<br>
before resuming at the new place. This happens on two
frontends, and<br>
never happened before. Is there a regression in this
version?<br>
<br>
</blockquote>
<div><br>
</div>
<div>This sounds very similar to <a moz-do-not-send="true"
href="http://code.mythtv.org/trac/ticket/11435">http://code.mythtv.org/trac/ticket/11435</a> ,
which was closed without fixing only because the OP had
a custom 0.26 build cherry-picking many of the Master
commits, making it very hard to reproduce.</div>
<div><br>
</div>
<div style="">Does this behavior happen only on new
recordings since your upgrade, or does it happen with
older recordings as well?</div>
<div style=""><br>
</div>
<div style="">Jim</div>
<div><br>
</div>
<br>
</div>
</div>
</div>
</blockquote>
I have opened a bug report for the problems (Ticket #11459).<br>
I am not sure but I think it happens on older recordings as well.
I will check and let you know. There is also another symptom that
I found. On a transcoded 720p recording (H264 mkv file) sometimes
a seek forward 1 minute actually goes back 5 or 10 minutes.
This is definitely on an older recording, and there is no seek
table on this one because mkv files do not have a seek table.<br>
Peter<br>
<br>
</blockquote>
On the weekend I downgraded my backend to
mythtv_0.26.0+fixes.20130131.28144cd to avoid this problem. I
downgraded the backend machine but did not downgrade the frontend
that runs on a different computer. Now the problem is gone from both
frontends (the one that shares the backend machine with 20130131
version and the separate frontend with 20130308 version). I have
tried with recordings done recently and older ones (recordings from
on both 20130131 and 20130308 versions). <br>
<br>
Let me know if you want me to upgrade again on the weekend and try
some tests. Today I also ran the optimize_mythdb.pl as suggested by
Michael Dean. I have never run the optimize before. I don't know if
database slowness could have caused my problem. I don't think so
because the problems went away when I downgraded back to 20130131.<br>
<br>
Peter<br>
</body>
</html>