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
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
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.
- 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.
Oliver
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
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
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
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.
- 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?
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.
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...
Oliver
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
Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:
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.
Hm, this is not required for my S2-6400.
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.
I am pretty sure that something is wrong. With the following (ugly) patch, the problem is gone:
--- vdr-2.3.9.org/menu.c 2018-03-18 13:01:09.000000000 +0100 +++ vdr-2.3.9/menu.c 2018-04-01 18:13:14.701413905 +0200 @@ -5726,7 +5726,19 @@ void cReplayControl::ShowMode(void) bool cReplayControl::ShowProgress(bool Initial) { int Current, Total; + +#if 1 // OE + static int count = 0; + + if (lastProgressUpdate == 0) + count = 2; // 0/1: problem, 2: fixed + else if (count > 0) + count--; + + if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1 || count > 0) { +#else if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { +#endif if (GetFrameNumber(Current, Total) && Total > 0) { if (!visible) { displayReplay = Skins.Current()->DisplayReplay(modeOnly);
All it does is executing the code in 'if (Initial...)' one more time, after lastProgressUpdate has been set to 0.
Of course, it does not affect the 'jumping' progress bar. See below.
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?
It does not make any difference, whether I use the keyboard or a real remote control. (Well, I use the remote plugin, not LIRC.)
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.
I don't care about I-frames. I use the cutter to produce small audio or video clips. The current behavior of the progress bar is annoying, when I play these clips. Anyway, I can easily revert the code to get the old behavior.
Oliver
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:
--- vdr-2.3.9.org/menu.c 2018-03-18 13:01:09.000000000 +0100 +++ vdr-2.3.9/menu.c 2018-04-01 18:13:14.701413905 +0200 @@ -5726,7 +5726,19 @@ void cReplayControl::ShowMode(void) bool cReplayControl::ShowProgress(bool Initial) { int Current, Total;
+#if 1 // OE
- static int count = 0;
- if (lastProgressUpdate == 0)
count = 2; // 0/1: problem, 2: fixed- else if (count > 0)
count--;- if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1 || count > 0) {
+#else if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) { +#endif if (GetFrameNumber(Current, Total) && Total > 0) { if (!visible) { displayReplay = Skins.Current()->DisplayReplay(modeOnly);
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.
Of course, it does not affect the 'jumping' progress bar. See below. ...
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.
I don't care about I-frames. I use the cutter to produce small audio or video clips. The current behavior of the progress bar is annoying, when I play these clips. Anyway, I can easily revert the code to get the old behavior.
Is the jumping mainly with radio recordings? If so, that could be explained by the lastProgressUpdate timeout, because in radio recordings every frame is considered to be an "I-frame", while in video recordings I-frames are typically spaced 0.5 to 1 second.
Let's first see whether the above patch fixes your sluggish marks display, and then continue with the jumping progress bar.
Klaus
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.
Of course, it does not affect the 'jumping' progress bar. See below. ...
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.
I don't care about I-frames. I use the cutter to produce small audio or video clips. The current behavior of the progress bar is annoying, when I play these clips. Anyway, I can easily revert the code to get the old behavior.
Is the jumping mainly with radio recordings?
No, it happens with all types of recordings - radio, SD and HD. It depends on the _length_ of the recording. The recording must be short, otherwise the effect is not visible.
If so, that could be explained by the lastProgressUpdate timeout, because in radio recordings every frame is considered to be an "I-frame", while in video recordings I-frames are typically spaced 0.5 to 1 second.
It has nothing to with I-frames. It is solely caused by the lastProgressUpdate timeout, which is 1 second. Try this:
Create a 2..3 minutes recording. Play it. You will see that the progress display is not moving smoothly, because it is updated every second.
Let's first see whether the above patch fixes your sluggish marks display, and then continue with the jumping progress bar.
I am not sure if you want to implement a dynamic update of the progress bar: The progress bar should be updated more often, when the recording is short...
Oliver
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
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
On 02.04.2018 12:35, Torgeir Veimo wrote:
Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:
At the time this was done, I was still using the TT S2-6400 as output device.
Jut curious, what are you using now? A raspberry pi?
Currently a Raspberry Pi, but I'm planning to use my J3455M board's graphics with softhddevice (or vaapidevice).
Klaus
Do you have any plans for more integrated means of running a client server setup like the streamdev setup? I like the raspberry pi since it's low power, and does hdmi-cec, but without sata I'm concerned with disk bandwidth with multiple recordings.
On 2 April 2018 at 21:27, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 02.04.2018 12:35, Torgeir Veimo wrote:
Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:
At the time this was done, I was still using the TT S2-6400 as output
device.
Jut curious, what are you using now? A raspberry pi?
Currently a Raspberry Pi, but I'm planning to use my J3455M board's graphics with softhddevice (or vaapidevice).
Klaus
vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 02.04.2018 14:22, Torgeir Veimo wrote:
Do you have any plans for more integrated means of running a client server setup like the streamdev setup? I like the raspberry pi since it's low power, and does hdmi-cec, but without sata I'm concerned with disk bandwidth with multiple recordings.
This already works very good with remote timers in VDR 2.3.9 (that's the setup I currently use). For replaying recordings I just mount the server's video directory on the RasPi. There's more to come after version 2.4.0 ;-).
Klaus
-
Klaus Schmidinger -
Oliver Endriss -
Torgeir Veimo