Reinhard, you have done an amazing job with the xine plugin. It works very well and considering xine's complexity, I can appreciate the hard work that must have been required to get both the infrastructure in xine and the plugin itself working as well as it does today.
I noticed, however, that it is extremely hard to use VDRs cutting function with it.
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, so I am basically forced to navigate in complete darkness.
Is that a known bug? Does it happen only in my setup (TT-budget S2-3200, GeForce 9500GT with VDPAU)? Is there a configuration option I can tweak to fix it?
Thanks in advance for any hints, Carsten.
Hi
Same problem here, was thinking it was my setup who was wrong.
By the way I saw also a big latency when you stop the replay of recordings to live TV , whatever was the button used (Blue button or Menu Back) , the live video freeze for 2-3 seconds , VDR is inoperative (no access to menu) during this time
Hope this help to debug
Have a nice day
Selon Carsten Koch CarstenKochElsdorf@web.de:
Reinhard, you have done an amazing job with the xine plugin. It works very well and considering xine's complexity, I can appreciate the hard work that must have been required to get both the infrastructure in xine and the plugin itself working as well as it does today.
I noticed, however, that it is extremely hard to use VDRs cutting function with it.
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, so I am basically forced to navigate in complete darkness.
Is that a known bug? Does it happen only in my setup (TT-budget S2-3200, GeForce 9500GT with VDPAU)? Is there a configuration option I can tweak to fix it?
Thanks in advance for any hints, Carsten.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Maybe it is not related to the vdr-xine plugin, could be with the VDR version, more specifically TS format? I'm having the same problem as described by Carsten with the xineliboutput plugin, on vdr-1.7.4.
dplu@free.fr wrote:
Hi
Same problem here, was thinking it was my setup who was wrong.
By the way I saw also a big latency when you stop the replay of recordings to live TV , whatever was the button used (Blue button or Menu Back) , the live video freeze for 2-3 seconds , VDR is inoperative (no access to menu) during this time
Hope this help to debug
Have a nice day
Selon Carsten Koch CarstenKochElsdorf@web.de:
Reinhard, you have done an amazing job with the xine plugin. It works very well and considering xine's complexity, I can appreciate the hard work that must have been required to get both the infrastructure in xine and the plugin itself working as well as it does today.
I noticed, however, that it is extremely hard to use VDRs cutting function with it.
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, so I am basically forced to navigate in complete darkness.
Is that a known bug? Does it happen only in my setup (TT-budget S2-3200, GeForce 9500GT with VDPAU)? Is there a configuration option I can tweak to fix it?
Carsten Koch schrieb:
Reinhard, you have done an amazing job with the xine plugin. It works very well and considering xine's complexity, I can appreciate the hard work that must have been required to get both the infrastructure in xine and the plugin itself working as well as it does today.
I noticed, however, that it is extremely hard to use VDRs cutting function with it.
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated,
works here (except in very rare cases with certain video material) Joerg
so I am basically forced to navigate in complete darkness.
Is that a known bug? Does it happen only in my setup (TT-budget S2-3200, GeForce 9500GT with VDPAU)? Is there a configuration option I can tweak to fix it?
Thanks in advance for any hints, Carsten.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi!
Carsten Koch schrieb:
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, so I am basically forced to navigate in complete darkness.
Huh, I always thought this was because of my graphics card (AMD RS690 with radeon driver) when I tried it with the xine or xineliboutput plugin. Thus I still use the softdevice plugin on my desktop. (which has other problems, but is at least usable for cutting recordings). VDR is 1.6.0.
VDR with xine was always "one keypress behind" when cutting, sounds like the symptoms you describe.
Ciao
Martin
Hi,
have compile errors with gcc 4.4. The attached patch makes vdr 1.7.7 compileable. What google told me, gcc 4.4 also affects 1.6.0.
cu
Edgar (gimli) Hucek
Hi,
Attached is an updated patch, which also extends tools.h to return char *.
Hi,
have compile errors with gcc 4.4. The attached patch makes vdr 1.7.7 compileable. What google told me, gcc 4.4 also affects 1.6.0.
cu
Edgar (gimli) Hucek_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Wed, 2009-05-27 at 16:40 +0200, gimli wrote: ...
have compile errors with gcc 4.4. The attached patch makes vdr 1.7.7 compileable.
I wonder if it would not be better to make as many things as possible "const" rather than casting existing consts away.
I my code, I am trying to make everything const that I do not have to change. It allows the compiler to make additional optimizations and it is safer (protects against unintended modifications).
Carsten.
Sure, the patch is not the best solution. You are right, whats to ment const should be const. In the first step it's more or less a speed fix :D
On Wed, 2009-05-27 at 16:40 +0200, gimli wrote: ...
have compile errors with gcc 4.4. The attached patch makes vdr 1.7.7 compileable.
I wonder if it would not be better to make as many things as possible "const" rather than casting existing consts away.
I my code, I am trying to make everything const that I do not have to change. It allows the compiler to make additional optimizations and it is safer (protects against unintended modifications).
Carsten.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I demand that gimli may or may not have written...
have compile errors with gcc 4.4. The attached patch makes vdr 1.7.7 compileable.
Why is that a follow-up, and not the start of a new thread?
Hi,
Carsten Koch schrieb:
I noticed, however, that it is extremely hard to use VDRs cutting function with it.
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, so I am basically forced to navigate in complete darkness.
Is that a known bug?
Well, yes, but I didn't find time to look into a sample till tonight. Please find attached the fix, at least for the sample I was working with.
Bye.
Hi
Many thanks for the fix, it works perfectly ;o) Have a nice day
Dom
Le Wednesday 27 May 2009 23:53:44 Reinhard Nissl, vous avez écrit :
Hi,
Carsten Koch schrieb:
I noticed, however, that it is extremely hard to use VDRs cutting function with it.
For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, so I am basically forced to navigate in complete darkness.
Is that a known bug?
Well, yes, but I didn't find time to look into a sample till tonight. Please find attached the fix, at least for the sample I was working with.
Bye.