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 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 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 ;-).

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?

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.

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