Am Montag, den 02.04.2018, 18:40 +0200 schrieb Klaus Schmidinger:
> On 02.04.2018 14:20, Oliver Endriss wrote:
> > 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.
>
> Taking a step back and considering that GetFrameNumber() was supposed to
> be a drop-in replacement for GetIndex(), just returning the exact number
> of the currently replayed frame and not just the index into the 'index'
> file (which, apart from I-frames, is typically different) I revoked the
> whole change and simply replaced GetIndex() with GetFrameNumber(). That
> resulted in the sluggish progress display on the Raspberry Pi I reported
> earlier. I then found that this was caused by the extra Flush() calls in
> cReplayControl::ShowProgress(). So I removed them and now everything runs
> smoothly on the RasPi and also on softhddevice.
> So please try the attached patch instead of the previous one, and especially
> check whether it still works on the dvbsddevice. This should hopefully also
> fix the "jumping progress display".
Works fine with HD/SD/radio recordings. Tested with dvbhddevice
and dvbsddevice. Both problems are fixed. Thank you.
> There is, apparently, still a problem on the RasPi, where once you set
> a mark, a subsequent "play" doesn't take effect until a couple of seconds
> later. However, since this doesn't occur with softhddevice, I assume this
> is a RasPi specific problem. I'll discuss this with Thomas separately.
This does not occur with the FF cards.
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
