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 vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
