[vdr] [vdr 2.3.9] Setting a mark is sluggish

Oliver Endriss o.endriss at gmx.de
Mon Apr 2 23:25:51 UTC 2018


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/
----------------------------------------------------------------




More information about the vdr mailing list