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

[Oliver Endriss]

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?
> 
> >> - 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!

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

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

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/



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

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

[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?


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

If you like, we can continue this in private.

Klaus

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

Re: [vdr] [ANNOUNCE] VDR developer version 2.3.9

[YUP]

Hi Klaus,

My contribution to the translation of VDR.

Regards,
Yarema

2018-03-18 14:54 GMT+01:00 Klaus Schmidinger :
> VDR developer version 2.3.9 is now available at
>
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.9.tar.bz2
>
> A 'diff' against the previous version is available at
>
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.8-2.3.9.diff
>
> MD5 checksums:
>
> 9e4202b046df9ea960d930ce99e967ab  vdr-2.3.9.tar.bz2
> 38a0f436fbed219665725aa2e54a9ca0  vdr-2.3.8-2.3.9.diff
>
> Approaching version 2.4.0:
> ==
>
> If there are no more serious bug reports, the final version 2.4.0 of VDR
> shall be released on April 15.
> So please test this developer version intensely and report any problems
> you might encounter as soon as possible.
>
> The following language files still have the given number of untranslated
> texts:
>
> PLUGINS/src/hello/po/ca_ES.po: 6
> PLUGINS/src/hello/po/da_DK.po: 6
> PLUGINS/src/hello/po/el_GR.po: 6
> PLUGINS/src/hello/po/es_ES.po: 6
> PLUGINS/src/hello/po/fr_FR.po: 6
> PLUGINS/src/hello/po/hu_HU.po: 6
> PLUGINS/src/hello/po/nl_NL.po: 6
> PLUGINS/src/hello/po/nn_NO.po: 6
> PLUGINS/src/hello/po/pt_PT.po: 6
> PLUGINS/src/hello/po/ro_RO.po: 6
> PLUGINS/src/hello/po/sl_SI.po: 6
> PLUGINS/src/hello/po/sv_SE.po: 6
> po/ar.po: 76
> po/ca_ES.po: 76
> po/cs_CZ.po: 22
> po/da_DK.po: 208
> po/el_GR.po: 271
> po/es_ES.po: 22
> po/et_EE.po: 7
> po/fi_FI.po: 3
> po/fr_FR.po: 22
> po/hr_HR.po: 208
> po/hu_HU.po: 22
> po/it_IT.po: 3
> po/lt_LT.po: 22
> po/mk_MK.po: 22
> po/nl_NL.po: 22
> po/nn_NO.po: 336
> po/pt_PT.po: 104
> po/ro_RO.po: 22
> po/ru_RU.po: 10
> po/sk_SK.po: 22
> po/sl_SI.po: 77
> po/sr_RS.po: 76
> po/sv_SE.po: 22
> po/tr_TR.po: 208
> po/uk_UA.po: 22
> po/zh_CN.po: 76
>
> If nobody takes care of these, they will remain untranslated in version
> 2.4.0.
>
>
>
> The changes since version 2.3.8:
>
> - Updated the Italian OSD texts (thanks to Diego Pierotto).
> - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
> - Fixed a possible crash when stopping VDR (thanks to Matthias Senzel for
> reporting and
>   helping to debug this one).
> - Fixed handling VPS events outside the LingerLimit, which could cause
> recordings to
>   stop prematurely (thanks to Johann Friedrichs).
> - Fixed an invalid lock sequence when trying to remove a deleted recording
> in case
>   of low disk space.
> - Now making sure that AssertFreeDiskSpace() is called with the maximum
> timer
>   priority in case there are several timers recording with different
> priorities.
> - The MTD mapper now avoids immediately reusing unique PIDs when switching
> channels,
>   to prevent possible problems with old data in buffers (thanks to Onur
> Sentürk).
> - The function cDevice::GetVideoSystem() (which has been deprecated since
> version 2.1.6)
>   has been finally removed.
> - The macros used to control deprecated code or functions have been changed
> to hold
>   numeric values (0 and 1), so that they can be controlled at compile time,
> without
>   having to edit the actual source code (suggested by Jasmin Jessich).
> - The default for DEPRECATED_VDR_CHARSET_OVERRIDE has been set to 0, which
> means VDR
>   no longer reacts on the environment variable VDR_CHARSET_OVERRIDE. You can
> add
>   'DEPRECATED_VDR_CHARSET_OVERRIDE=1' when compiling in order to restore
> this
>   functionality. However, it is recommended to use the command line option
> --chartab
>   instead.
> - The timeout for the channel display is now reset whenever the channel or
> EPG data
>   changes.
> - OSD menus now try to keep the offset of the list cursor at a constant
> position on
>   the screen, even if the list is modified while being displayed.
> - The LCARS skin's main menu now reacts to changes of the current channel's
> name.
> - If an event in the Schedules menu is marked with a 'T' or 'I' and the user
> presses the
>   Red button to edit the timer, local timers are now preferred over remote
> timers
>   in case there is more than one timer that will record that event.
> - Switching the primary device is no longer done via osSwitchDvb (which has
> been
>   removed), but rather by the main program loop reacting to changes in
> Setup.PrimaryDVB.
> - The new SVDRP commands 'LSTD' and 'PRIM' can be used to list all available
> devices
>   and to switch the primary device (thanks to Thomas Reufer).
> - Added some comments regarding font height (thanks to Thomas Reufer).
> - Fixed handling timers during the change from DST to winter time (thanks to
> Johann
>   Friedrichs).
> - Added missing checks of 'player' in member functions of cControl, and
> setting
>   cControl::player to NULL in cDvbPlayerControl::Stop() to avoid a possible
> crash
>   with plugins that retrieve player information after a replay has been
> stopped, but
>   before the replay control has been destroyed (thanks to Johann Friedrich).
> - Now calling Hide() and cStatus::MsgReplaying(..., false) from
> 

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

[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?
- If applicable: Does it also happen with the LCARS skin?
- Are you running any plugins that utilize the cStatus::MarksModified() 
function?
- If none of the above: can you determine which version between 2.2.0 and
  2.3.9 introduced this?

Klaus

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

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

[Oliver Endriss]

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?

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/




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

Re: [vdr] [ANNOUNCE] VDR developer version 2.3.9

[Klaus Schmidinger]

On 18.03.2018 17:59, Wolfgang Rohdewald wrote:

On So, 2018-03-18 at 14:54 +0100, Klaus Schmidinger wrote:

- Disabled the use of posix_fadvise() when reading (i.e. replaying), since it 
caused
   stuttering replay in fast forward and fast rewind mode in case the video 
directory
   is mounted via NFS. You can re-enable it by setting the macro 
USE_FADVISE_READ to 1
   in tools.c.


Will it be possible to do that at compile time without changing the source code
like you now do for the deprecated function?


Yes, that should be possible.

Klaus


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

Re: [vdr] [ANNOUNCE] VDR developer version 2.3.9

[Wolfgang Rohdewald]

On So, 2018-03-18 at 14:54 +0100, Klaus Schmidinger wrote:
> - Disabled the use of posix_fadvise() when reading (i.e. replaying), since it 
> caused
>stuttering replay in fast forward and fast rewind mode in case the video 
> directory
>is mounted via NFS. You can re-enable it by setting the macro 
> USE_FADVISE_READ to 1
>in tools.c.

Will it be possible to do that at compile time without changing the source code
like you now do for the deprecated function?

-- 
Wolfgang

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

[vdr] [ANNOUNCE] VDR developer version 2.3.9

[Klaus Schmidinger]

VDR developer version 2.3.9 is now available at

  ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.9.tar.bz2

A 'diff' against the previous version is available at

  ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.8-2.3.9.diff

MD5 checksums:

9e4202b046df9ea960d930ce99e967ab  vdr-2.3.9.tar.bz2
38a0f436fbed219665725aa2e54a9ca0  vdr-2.3.8-2.3.9.diff

Approaching version 2.4.0:
==

If there are no more serious bug reports, the final version 2.4.0 of VDR
shall be released on April 15.
So please test this developer version intensely and report any problems
you might encounter as soon as possible.

The following language files still have the given number of untranslated texts:

PLUGINS/src/hello/po/ca_ES.po: 6
PLUGINS/src/hello/po/da_DK.po: 6
PLUGINS/src/hello/po/el_GR.po: 6
PLUGINS/src/hello/po/es_ES.po: 6
PLUGINS/src/hello/po/fr_FR.po: 6
PLUGINS/src/hello/po/hu_HU.po: 6
PLUGINS/src/hello/po/nl_NL.po: 6
PLUGINS/src/hello/po/nn_NO.po: 6
PLUGINS/src/hello/po/pt_PT.po: 6
PLUGINS/src/hello/po/ro_RO.po: 6
PLUGINS/src/hello/po/sl_SI.po: 6
PLUGINS/src/hello/po/sv_SE.po: 6
po/ar.po: 76
po/ca_ES.po: 76
po/cs_CZ.po: 22
po/da_DK.po: 208
po/el_GR.po: 271
po/es_ES.po: 22
po/et_EE.po: 7
po/fi_FI.po: 3
po/fr_FR.po: 22
po/hr_HR.po: 208
po/hu_HU.po: 22
po/it_IT.po: 3
po/lt_LT.po: 22
po/mk_MK.po: 22
po/nl_NL.po: 22
po/nn_NO.po: 336
po/pt_PT.po: 104
po/ro_RO.po: 22
po/ru_RU.po: 10
po/sk_SK.po: 22
po/sl_SI.po: 77
po/sr_RS.po: 76
po/sv_SE.po: 22
po/tr_TR.po: 208
po/uk_UA.po: 22
po/zh_CN.po: 76

If nobody takes care of these, they will remain untranslated in version 2.4.0.



The changes since version 2.3.8:

- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Fixed a possible crash when stopping VDR (thanks to Matthias Senzel for 
reporting and
  helping to debug this one).
- Fixed handling VPS events outside the LingerLimit, which could cause 
recordings to
  stop prematurely (thanks to Johann Friedrichs).
- Fixed an invalid lock sequence when trying to remove a deleted recording in 
case
  of low disk space.
- Now making sure that AssertFreeDiskSpace() is called with the maximum timer
  priority in case there are several timers recording with different priorities.
- The MTD mapper now avoids immediately reusing unique PIDs when switching 
channels,
  to prevent possible problems with old data in buffers (thanks to Onur 
Sentürk).
- The function cDevice::GetVideoSystem() (which has been deprecated since 
version 2.1.6)
  has been finally removed.
- The macros used to control deprecated code or functions have been changed to 
hold
  numeric values (0 and 1), so that they can be controlled at compile time, 
without
  having to edit the actual source code (suggested by Jasmin Jessich).
- The default for DEPRECATED_VDR_CHARSET_OVERRIDE has been set to 0, which 
means VDR
  no longer reacts on the environment variable VDR_CHARSET_OVERRIDE. You can add
  'DEPRECATED_VDR_CHARSET_OVERRIDE=1' when compiling in order to restore this
  functionality. However, it is recommended to use the command line option 
--chartab
  instead.
- The timeout for the channel display is now reset whenever the channel or EPG 
data
  changes.
- OSD menus now try to keep the offset of the list cursor at a constant 
position on
  the screen, even if the list is modified while being displayed.
- The LCARS skin's main menu now reacts to changes of the current channel's 
name.
- If an event in the Schedules menu is marked with a 'T' or 'I' and the user 
presses the
  Red button to edit the timer, local timers are now preferred over remote 
timers
  in case there is more than one timer that will record that event.
- Switching the primary device is no longer done via osSwitchDvb (which has been
  removed), but rather by the main program loop reacting to changes in 
Setup.PrimaryDVB.
- The new SVDRP commands 'LSTD' and 'PRIM' can be used to list all available 
devices
  and to switch the primary device (thanks to Thomas Reufer).
- Added some comments regarding font height (thanks to Thomas Reufer).
- Fixed handling timers during the change from DST to winter time (thanks to 
Johann
  Friedrichs).
- Added missing checks of 'player' in member functions of cControl, and setting
  cControl::player to NULL in cDvbPlayerControl::Stop() to avoid a possible 
crash
  with plugins that retrieve player information after a replay has been 
stopped, but
  before the replay control has been destroyed (thanks to Johann Friedrich).
- Now calling Hide() and cStatus::MsgReplaying(..., false) from 
cReplayControl::Stop(),
  to inform plugins about an ending replay session before the replay control 
gets
  destroyed.
- Fixed a possible crash when moving a recording between different volumes 
(reported by
  Matthias Senzel).
- Fixed positioning the cursor in the Recordings menu when moving a recording 
between
  different volumes.
- Added a note to PLUGINS.html about writing log messages in English.
-