Re: [vdr 2.3.9] Setting a mark is sluggish

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19.03.2018 18:01, Oliver Endriss wrote:
Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:
On 19.03.2018 01:33, Oliver Endriss wrote:
> Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
>> On 18.03.2018 20:39, Oliver Endriss wrote:
>> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
>> >> On 18.03.2018 18:55, Oliver Endriss wrote:
>> >> > Hi,
>> >> > >> >> > just installed vdr 2.3.9 and noticed that there is a delay
>> >> > when I try to set a recording mark, compared with vdr 2.2.0.
>> >> > >> >> > Steps to reproduce:
>> >> > - Play a recording.
>> >> > - Press ok to display the progress bar.
>> >> > - Press 0 to set a mark.
>> >> > >> >> > There is a notable delay between the keypress
>> >> > and the mark showing up.
>> >> > >> >> > Can someone confirm this? >> >> >> >> Tried it while replaying on a Raspberry Pi, with the video directory
>> >> mounted via NFS, and had no unusual delay.
>> >> >> >> - Which skin are you using?
>> > Classic skin.
>> > >> >> - If applicable: Does it also happen with the LCARS skin?
>> > Yes.
>> > >> >> - Are you running any plugins that utilize the cStatus::MarksModified() function?
>> > No. Test setup: vdr + dvbsddevice + remote.
>> >> I'm afraid I don't have a working VDR with the old FF card any more, so
>> I can't test on that hardware. It doesn't happen with the Raspberry Pi, though.
>> >> Does it make a difference whether the progress display is active or not
>> when you set the mark?

Can you comment on this one?

If the progress bar is off, and you set a mark, progress bar and
mark show up immediately. -> No problem.

Very good!

>> >> - If none of the above: can you determine which version between 2.2.0 and
>> >>    2.3.9 introduced this?
>> > >> > Ok. I went back in time and installed the older versions.
>> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
>> >> The only change that was introduced in that area between these two versions
>> is in cReplayControl::ShowProgress():
>> >> if (Initial || time(NULL) - lastProgressUpdate >= 1) { >> >> Please try commenting out that line and the corresponding closing '}'.
>> While I don't see why this would only be a problem on dvbsddevice and not
>> on rpihddevice, I strongly suspect it to be the culprit.
> > Yes, this fixes the issue completely!

If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).

So is this a workaround for the Raspberry?

Not in particular.
At the time this was done, I was still using the TT S2-6400 as output device.

> In vdr-2.3.9 the line looks like
>   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
> > As a consequence, the mark shows up immediately during fast-forward,
> while it is displayed with (variable) delay in play mode.

In cReplayControl::ProcessKey() there is

   if (Key != kNone)
      lastProgressUpdate = 0;

so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
always be true immediately after a key has been pressed ('0' in case of
setting a mark).
Can you verify this by adding some debug output?

Debug output indicates that this is true.

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.

While trying to reproduce this I saw that my LIRC remote control sometimes
"misses" a keypress, which makes the whole thing appear "sluggish".
When I set/remove a mark with the '0' key on the PC's keyboard, it works
just fine every time.

Do you see any difference in behavior between the (LIRC?) remote control
and using the keyboard?

> In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
> is affected, too.
> > Anyway, I do not understand why rpihddevice should behave differently.
> Does this device have a slow OSD? In this case you might not notice...

The OSD on the RasPi is a lot faster than that on the old FF cards.

> I will update my dvbhddevice vdr to vdr-2.3.9 soon.
> I expect that it affected the same way.

I used a TT S2-6400 until recently (the motherboard is broken) and had no
problems setting editing marks. I'm curious to see what your experience
will be.

Update: The HD FF behaves exactly the same way as the SD FF.

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.

Klaus


_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux