Reinhard Nissl wrote:
Previously, when a PTS wrap happend, xine stopped replay for about 26.5 hours.
Heh, that's a quite long time... but still I'd prefer the picture to jump rather than audio...
Did you patch VDR-1.3.23 with vdr-1.3.23-dvbplayer3.patch?
Yes I did. In 1.3.22+0.7.2 combo I have the very first (if I remember correctly) dvbplayer patch sent to the list.
If this patch doesn't fix the rewind issue, would you please be so
kind
and explain in detail, what's going wrong?
When I press e.g. ff-rewind, VDR starts to rewind, but the rewind picture updates do not happen as often as they should (perhaps 3 picture updates / second). And after few seconds the rewind freezes completely as if I had pressed pause.
Pressing play at that point does not do anything at first, but after waiting for some time VDR wakes up again and continues normal playback.
Please include the output of VDR and xine --verbose=2 when you select rewind.
I forgot to pipe VDR output to file, but for xine output see here: http://tvr.dy.fi/xine.log
I started vdr, then started xine, went directly to a recording, started ff-rewind, waited few seconds until it got stuck, waited for some time (this time vdr didn't wake up, I may have pressed play couple more times), pressed finally q in xine to quit.
Teemu
Hi,
Rantanen Teemu wrote:
When I press e.g. ff-rewind, VDR starts to rewind, but the rewind picture updates do not happen as often as they should (perhaps 3 picture updates / second). And after few seconds the rewind freezes completely as if I had pressed pause.
There is a known issue that switching to tickmodes makes xine pause for quite a while (several frames).
Pressing play at that point does not do anything at first, but after waiting for some time VDR wakes up again and continues normal playback.
Please include the output of VDR and xine --verbose=2 when you select rewind.
I forgot to pipe VDR output to file, but for xine output see here: http://tvr.dy.fi/xine.log
Strange is, that you have that large numbers in CLEAR(...). I'd say, vdr-xine and input_vdr.[ch] do not match. The number in brackets is a sequence number, and typically it matches the number which vdr-xine outputs. I've used it to debug some deadlock situations before I've released 0.7.3.
I started vdr, then started xine, went directly to a recording, started ff-rewind, waited few seconds until it got stuck, waited for some time (this time vdr didn't wake up, I may have pressed play couple more times), pressed finally q in xine to quit.
Whenever there is a clock error, you're lost. You'll have to wait until cur_vpts reaches next_vpts before playback continues.
Bye.