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?

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

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