Message ID | c4b50264-e892-9c8a-c3f9-0082d44a8a8a@tvdr.de |
---|---|
State | New |
Headers |
Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <vdr-bounces@linuxtv.org>) id 1f2wh6-0001Dy-IB; Mon, 02 Apr 2018 10:28:08 +0000 Received: from racoon.tvdr.de ([88.198.76.220]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <Klaus.Schmidinger@tvdr.de>) id 1f2wh1-0001Dc-Dd for vdr@linuxtv.org; Mon, 02 Apr 2018 10:28:04 +0000 Received: from eagle.tvdr.de (eagle.tvdr.de [192.168.1.10]) by racoon.tvdr.de (8.14.9/8.14.9) with ESMTP id w32AS1ls022477 for <vdr@linuxtv.org>; Mon, 2 Apr 2018 12:28:01 +0200 Received: from [192.168.1.10] (eagle.tvdr.de [192.168.1.10]) by eagle.tvdr.de (8.15.2/8.15.2) with ESMTP id w32AS1QG022703 for <vdr@linuxtv.org>; Mon, 2 Apr 2018 12:28:01 +0200 To: vdr@linuxtv.org References: <1521395713.25906.32.camel@gmx.de> <9087fe44-7a55-04d9-db1b-f01efd1728f2@tvdr.de> <1521401970.25906.39.camel@gmx.de> <ad00615f-3e3f-c485-7ba5-52d5e0886261@tvdr.de> <1521419632.13788.23.camel@gmx.de> <187ea575-494a-bd6f-1b77-0afa47179d03@tvdr.de> <1521478893.13788.51.camel@gmx.de> <86ccd436-7b0d-e3cd-6828-b72b354e3e63@tvdr.de> <1522602109.21255.40.camel@gmx.de> From: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> Message-ID: <c4b50264-e892-9c8a-c3f9-0082d44a8a8a@tvdr.de> Date: Mon, 2 Apr 2018 12:28:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1522602109.21255.40.camel@gmx.de> Content-Language: de-DE X-LSpam-Score: -1.9 (-) X-LSpam-Report: No, score=-1.9 required=5.0 tests=BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01 autolearn=ham autolearn_force=no Subject: Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <https://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr/> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> Reply-To: VDR Mailing List <vdr@linuxtv.org> Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: vdr-bounces@linuxtv.org Sender: "vdr" <vdr-bounces@linuxtv.org> |
Commit Message
Klaus Schmidinger
April 2, 2018, 10:28 a.m. UTC
On 01.04.2018 19:01, Oliver Endriss wrote: > ... >> >> >> Does it make a difference whether the progress display is active or not >> >> >> when you set the mark? >> > >> > If the progress bar is off, and you set a mark, progress bar and >> > mark show up immediately. -> No problem. >> >> ... >> > Could it be that this action is triggered _before_ the mark has been >> > written to the OSD buffer? In this case, the OSD would be displayed >> > without the mark, and the mark would be displayed during the next >> > cycle, i.e. one second later. >> >> I doubt that. Well, meanwhile I think you were right here. In cReplayControl::MarkToggle() there is lastCurrent = -1; // triggers redisplay which it used to do until the switch to GetFrameNumber() ;-). Now this has no immediate effect any more, and that may explain the sluggishness you observe. Please try this: > I am pretty sure that something is wrong. > With the following (ugly) patch, the problem is gone: > > --- vdr-2.3.9.org/menu.c 2018-03-18 13:01:09.000000000 +0100 > +++ vdr-2.3.9/menu.c 2018-04-01 18:13:14.701413905 +0200 > @@ -5726,7 +5726,19 @@ void cReplayControl::ShowMode(void) > bool cReplayControl::ShowProgress(bool Initial) > { > int Current, Total; > + > +#if 1 // OE > + static int count = 0; > + > + if (lastProgressUpdate == 0) > + count = 2; // 0/1: problem, 2: fixed > + else if (count > 0) > + count--; > + > + if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1 || count > 0) { > +#else > if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { > +#endif > if (GetFrameNumber(Current, Total) && Total > 0) { > if (!visible) { > displayReplay = Skins.Current()->DisplayReplay(modeOnly); > > > All it does is executing the code in 'if (Initial...)' one more time, > after lastProgressUpdate has been set to 0. Thanks for pointing this out. This triggered my idea with lastCurrent above. > Of course, it does not affect the 'jumping' progress bar. See below. > ... >> > Btw, with a short recording, you can see that the progress bar is >> > jumping in one second steps... >> >> That's pretty much the distance between the I-frames, and thus the steps in >> which VDR updates the progress bar. > > I don't care about I-frames. I use the cutter to produce small audio > or video clips. The current behavior of the progress bar is annoying, > when I play these clips. Anyway, I can easily revert the code to get > the old behavior. Is the jumping mainly with radio recordings? If so, that could be explained by the lastProgressUpdate timeout, because in radio recordings every frame is considered to be an "I-frame", while in video recordings I-frames are typically spaced 0.5 to 1 second. Let's first see whether the above patch fixes your sluggish marks display, and then continue with the jumping progress bar. Klaus
Comments
Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger: > On 01.04.2018 19:01, Oliver Endriss wrote: > > ... > >> >> >> Does it make a difference whether the progress display is active or not > >> >> >> when you set the mark? > >> > > >> > If the progress bar is off, and you set a mark, progress bar and > >> > mark show up immediately. -> No problem. > >> > >> ... > >> > Could it be that this action is triggered _before_ the mark has been > >> > written to the OSD buffer? In this case, the OSD would be displayed > >> > without the mark, and the mark would be displayed during the next > >> > cycle, i.e. one second later. > >> > >> I doubt that. > > Well, meanwhile I think you were right here. > In cReplayControl::MarkToggle() there is > > lastCurrent = -1; // triggers redisplay > > which it used to do until the switch to GetFrameNumber() ;-). > > Now this has no immediate effect any more, and that may explain > the sluggishness you observe. > > Please try this: > > --- menu.c 2018/03/24 11:43:40 4.70 > +++ menu.c 2018/04/02 10:07:05 > @@ -5728,7 +5728,7 @@ > bool cReplayControl::ShowProgress(bool Initial) > { > int Current, Total; > - if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { > + if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { > if (GetFrameNumber(Current, Total) && Total > 0) { > if (!visible) { > displayReplay = Skins.Current()->DisplayReplay(modeOnly); > > > I am pretty sure that something is wrong. > > With the following (ugly) patch, the problem is gone: > > ... > > All it does is executing the code in 'if (Initial...)' one more time, > > after lastProgressUpdate has been set to 0. > > Thanks for pointing this out. This triggered my idea with lastCurrent above. Thanks, your patch fixed the issue. > > Of course, it does not affect the 'jumping' progress bar. See below. > > ... > >> > Btw, with a short recording, you can see that the progress bar is > >> > jumping in one second steps... > >> > >> That's pretty much the distance between the I-frames, and thus the steps in > >> which VDR updates the progress bar. > > > > I don't care about I-frames. I use the cutter to produce small audio > > or video clips. The current behavior of the progress bar is annoying, > > when I play these clips. Anyway, I can easily revert the code to get > > the old behavior. > > Is the jumping mainly with radio recordings? No, it happens with all types of recordings - radio, SD and HD. It depends on the _length_ of the recording. The recording must be short, otherwise the effect is not visible. > If so, that could be explained by the lastProgressUpdate timeout, because > in radio recordings every frame is considered to be an "I-frame", while > in video recordings I-frames are typically spaced 0.5 to 1 second. It has nothing to with I-frames. It is solely caused by the lastProgressUpdate timeout, which is 1 second. Try this: Create a 2..3 minutes recording. Play it. You will see that the progress display is not moving smoothly, because it is updated every second. > Let's first see whether the above patch fixes your sluggish marks display, > and then continue with the jumping progress bar. I am not sure if you want to implement a dynamic update of the progress bar: The progress bar should be updated more often, when the recording is short... Oliver
--- menu.c 2018/03/24 11:43:40 4.70 +++ menu.c 2018/04/02 10:07:05 @@ -5728,7 +5728,7 @@ bool cReplayControl::ShowProgress(bool Initial) { int Current, Total; - if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { + if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { if (GetFrameNumber(Current, Total) && Total > 0) { if (!visible) { displayReplay = Skins.Current()->DisplayReplay(modeOnly);