I don't know if this feature is causing the problem, but with this
release of the plugin xine "freezes" after changing channels (not
always but quite frequently), it seems just after doing this trick
(i.e when speed has supposedly reached 100%). Sometimes if I wait
long enough (a minute or so) it will start working again, sometimes
pressing "q" will unlock video but no audio and xine won't respond to
any keypress. Sometimes pressing "q" would end xine. Most of the
times though I have to kill xine and run it again (vdr itself is
still working). I took the xine snapshot from the plugin home page,
and I tried increasing the prebuffer time with no success.
So the freeze happens just after VDR stops writing '.' to console, right?
Are there any 'P' characters or even 'Clear'?
Yes, there are, 12 P followed by Clear (but at least once, in a later
test run, no 'P's and no 'Clear' when xine froze). Note that the 'P's
start appearing a short while after the freeze.
Does 'xine --verbose=2' provide any useful information?
The (almost) last output should be 'set_speed 4' to prove your
observations.
set_speed 4
inserting 1098682314 0-frames to fill a gap of 2060532399 pts
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4332927
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4335567
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4337480
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4339456
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4341446
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4343418
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4345446
video_out: vpts/clock error, next_vpts=2064974481 cur_vpts=4347375
Isn't that strange: it was working perfectly for almost two weeks now, but
yesterday evening I realized the same behaviour. There is something wrong with
synchronizing the metronom to the new stream, so xine will wait "endlessly" to
reach next_vpts ((2064974481 - 4347375) / 90000) seconds).