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