Hi all,
I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press "up" to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to.
Is this a known bug or do I have to press other keys or is there a setting to change it?
Stefan
I believe that's a problem with the video decoder. I had the same problem using vdpau with vdr-xine long ago but it was quickly fixed. When I started testing vdr-softhddevice, the problem re-appeared. You can enable "CONFIG += -DH264_EOS_TRICKSPEED" in vdr-softhddevice/Makefile and it should work, assuming you're using vdr-softhddevice & are using a recent git of it.
On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg infos@nafets.dewrote:
Hi all,
I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press "up" to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to.
Is this a known bug or do I have to press other keys or is there a setting to change it?
Stefan
______________________________**_________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdrhttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
This problem still exists with vdr-sxfe and HD recordings.
On Tue, 27 Aug 2013 11:28:24 -0700 VDR User user.vdr@gmail.com wrote:
I believe that's a problem with the video decoder. I had the same problem using vdpau with vdr-xine long ago but it was quickly fixed. When I started testing vdr-softhddevice, the problem re-appeared. You can enable "CONFIG += -DH264_EOS_TRICKSPEED" in vdr-softhddevice/Makefile and it should work, assuming you're using vdr-softhddevice & are using a recent git of it.
On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg infos@nafets.dewrote:
Hi all,
I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press "up" to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to.
Is this a known bug or do I have to press other keys or is there a setting to change it?
Hi all,
Thanks for your ideas.
I am using an old (SD but not HD) FF PCI card and non-HD recordings. So neither of the situations you described applies as far as I understan.
Some more background: A lot of my recordings are done with VDR 1.6, but the symptom occurs both with old and new recordings. I currently dont have a HD device attached. I am running in a XEN-virualized Environment with PCI passthrough.
vVdr:~ # lspci -v 00:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at f7fff000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: av7110
00:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 18 Memory at f7ffe000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: av7110
Stefan
Am 27.08.2013 20:36, schrieb Tony Houghton:
This problem still exists with vdr-sxfe and HD recordings.
On Tue, 27 Aug 2013 11:28:24 -0700 VDR User user.vdr@gmail.com wrote:
I believe that's a problem with the video decoder. I had the same problem using vdpau with vdr-xine long ago but it was quickly fixed. When I started testing vdr-softhddevice, the problem re-appeared. You can enable "CONFIG += -DH264_EOS_TRICKSPEED" in vdr-softhddevice/Makefile and it should work, assuming you're using vdr-softhddevice & are using a recent git of it.
On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg infos@nafets.dewrote:
Hi all,
I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press "up" to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to.
Is this a known bug or do I have to press other keys or is there a setting to change it?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 27.08.2013 20:47, Stefan Schallenberg wrote:
Hi all,
Thanks for your ideas.
I am using an old (SD but not HD) FF PCI card and non-HD recordings. So neither of the situations you described applies as far as I understan.
Are you sure you are using the latest driver and firmware for that card? Old versions might not return the actual STC value.
Klaus
Some more background: A lot of my recordings are done with VDR 1.6, but the symptom occurs both with old and new recordings. I currently dont have a HD device attached. I am running in a XEN-virualized Environment with PCI passthrough.
vVdr:~ # lspci -v 00:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at f7fff000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: av7110
00:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 18 Memory at f7ffe000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: av7110
Stefan
Am 27.08.2013 20:36, schrieb Tony Houghton:
This problem still exists with vdr-sxfe and HD recordings.
On Tue, 27 Aug 2013 11:28:24 -0700 VDR User user.vdr@gmail.com wrote:
I believe that's a problem with the video decoder. I had the same problem using vdpau with vdr-xine long ago but it was quickly fixed. When I started testing vdr-softhddevice, the problem re-appeared. You can enable "CONFIG += -DH264_EOS_TRICKSPEED" in vdr-softhddevice/Makefile and it should work, assuming you're using vdr-softhddevice & are using a recent git of it.
On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg infos@nafets.dewrote:
Hi all,
I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press "up" to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to.
Is this a known bug or do I have to press other keys or is there a setting to change it?
Hi Klaus,
I am using OpenSUSE 12.3 with standard kernel 3.7.10. - do you think I need to switch to Liplianin or other driver packages forcing me to recompile parts of the kernel?
On the same system VDR 1.6 did not show the problem, does VDR 2.x handle DVB device (dvbsddevice plugin) different than 1.6?
Stefan
Am 27.08.2013 22:05, schrieb Klaus Schmidinger:
On 27.08.2013 20:47, Stefan Schallenberg wrote:
Hi all,
Thanks for your ideas.
I am using an old (SD but not HD) FF PCI card and non-HD recordings. So neither of the situations you described applies as far as I understan.
Are you sure you are using the latest driver and firmware for that card? Old versions might not return the actual STC value.
Klaus
Some more background: A lot of my recordings are done with VDR 1.6, but the symptom occurs both with old and new recordings. I currently dont have a HD device attached. I am running in a XEN-virualized Environment with PCI passthrough.
vVdr:~ # lspci -v 00:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at f7fff000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: av7110
00:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 18 Memory at f7ffe000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: av7110
Stefan
Am 27.08.2013 20:36, schrieb Tony Houghton:
This problem still exists with vdr-sxfe and HD recordings.
On Tue, 27 Aug 2013 11:28:24 -0700 VDR User user.vdr@gmail.com wrote:
I believe that's a problem with the video decoder. I had the same problem using vdpau with vdr-xine long ago but it was quickly fixed. When I started testing vdr-softhddevice, the problem re-appeared. You can enable "CONFIG += -DH264_EOS_TRICKSPEED" in vdr-softhddevice/Makefile and it should work, assuming you're using vdr-softhddevice & are using a recent git of it.
On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg infos@nafets.dewrote:
Hi all,
I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press "up" to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to.
Is this a known bug or do I have to press other keys or is there a setting to change it?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Stefan Schallenberg infos@nafets.de wrote:
Am 27.08.2013 22:05, schrieb Klaus Schmidinger:
On 27.08.2013 20:47, Stefan Schallenberg wrote:
Hi all,
Thanks for your ideas.
I am using an old (SD but not HD) FF PCI card and non-HD recordings. So neither of the situations you described applies as far as I understan.
Are you sure you are using the latest driver and firmware for that card? Old versions might not return the actual STC value.
Hi Klaus,
I am using OpenSUSE 12.3 with standard kernel 3.7.10. - do you think I need to switch to Liplianin or other driver packages forcing me to recompile parts of the kernel?
On the same system VDR 1.6 did not show the problem, does VDR 2.x handle DVB device (dvbsddevice plugin) different than 1.6?
From HISTORY: | 2009-04-12: Version 1.7.5 | ... | + cDevice::GetSTC() is now required to deliver the STC even in trick modes. | It is sufficient if it returns the PTS of the most recently presented | audio/video frame. | + The full-featured DVB cards need an improved firmware in order to return | proper STC values in trick modes. | ...
You can download an updated firmware from http://www.escape-edv.de/endriss/firmware/
CU Oliver
Thank you very much, Firmware fb2624 solved the problem.
Stefan
Am 28.08.2013 23:16, schrieb Oliver Endriss:
Stefan Schallenberg infos@nafets.de wrote:
Am 27.08.2013 22:05, schrieb Klaus Schmidinger:
On 27.08.2013 20:47, Stefan Schallenberg wrote:
Hi all,
Thanks for your ideas.
I am using an old (SD but not HD) FF PCI card and non-HD recordings. So neither of the situations you described applies as far as I understan.
Are you sure you are using the latest driver and firmware for that card? Old versions might not return the actual STC value.
Hi Klaus,
I am using OpenSUSE 12.3 with standard kernel 3.7.10. - do you think I need to switch to Liplianin or other driver packages forcing me to recompile parts of the kernel?
On the same system VDR 1.6 did not show the problem, does VDR 2.x handle DVB device (dvbsddevice plugin) different than 1.6?
From HISTORY: | 2009-04-12: Version 1.7.5 | ... | + cDevice::GetSTC() is now required to deliver the STC even in trick modes. | It is sufficient if it returns the PTS of the most recently presented | audio/video frame. | + The full-featured DVB cards need an improved firmware in order to return | proper STC values in trick modes. | ...
You can download an updated firmware from http://www.escape-edv.de/endriss/firmware/
CU Oliver
-
Klaus Schmidinger -
Oliver Endriss -
Stefan Schallenberg -
Tony Houghton -
VDR User