Reinhard Nissl wrote:
You don't have to be sorry: without the plugin I wouldn't have such problems but I couldn't use vdr, so... ;-)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.
I'm sorry for causing such troubles.
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.So the freeze happens just after VDR stops writing '.' to console, right? Are there any 'P' characters or even 'Clear'?
set_speed 4
Does 'xine --verbose=2' provide any useful information?
The (almost) last output should be 'set_speed 4' to prove your observations.
This happens on a 1Ghz celeron, vdr 1.3.11 using streamdev client with your patches applied (if that may be relevant).
Please tell a little bit about your hardware. It's likely that I don't run into your troubles using a Pentium 4 HT 2.8 GHz.
Attachment:
signature.asc
Description: OpenPGP digital signature