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

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Mon Apr 2 16:40:28 UTC 2018


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".

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.

Klaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdr-2.3.9-fixprogressdisplay.diff
Type: text/x-patch
Size: 3634 bytes
Desc: not available
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20180402/b4fb7024/attachment.bin>


More information about the vdr mailing list