Reinhard Nissl wrote:
> Well, have a look into xineDevice.c and locate
> cXineDevice::HasIBPTrickSpeed(). Then remove the comment and
> apply the attached patch to VDR.
> The problem is, that I don't know which speed calculation to use
> in SetTrickSpeed(). So I asked kls to supply this info as in the
> attached patch but he thinks of changing the semantic of
> SetTrickSpeed() at all. That's why I haven't released this
> functionality yet.
> Bye.
Thanks, but that unfortunately didn't help me. For me, ffwd/rew hasn't 
worked with vdr-xine since back in the days when you had to patch if for 
networked use. Then xineliboutput came along and I have never managed to 
get vdr-xine to work well enough to replace it. I guess I have tried 
about 100 different versions of hardware/vdr/graphics drivers/xinelib 
and vdr-xine over the years. The HD playback is better than in 
xineliboutput but what I do a lot is to jump 60s forward through 
recordings and that doesn't work very well with vdr-xine. The progress 
bar jumps 60s almost immediately, but it only jumps about five seconds. 
And a few seconds later, it jumps to where it should. With xineliboutput 
a can hold the button down and it jumps very fast and precise. And 
ffwd/rew is instantaneous. With vdr-xine, xine-ui crashes almost every 
time. And since I don't even have a GPU on my vdr server, I'm not very 
fond of having to compile xine on it. But like I said, vdr-xine works 
better with HD channels and plays Swedish national television's 720p50 
SVT HD which xineliboutput doesn't do very well so it would be nice to 
get it working. Actually, I tend to use XBMC to watch HD recordings 
since their vdpau implementation seems to be the best. Thanks for taking 
your time.
/Magnus H

vdr mailing list

Reply via email to