Re: [vdr 2.3.9] Setting a mark is sluggish

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

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------


_______________________________________________
vdr mailing list
[email protected]
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr