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
vdr@xxxxxxxxxxx
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
