Default-enabled Goom Visualization grinds to a halt

[TEN]

Binary package hint: vdr-plugin-xineliboutput

When switching to radio channels (i.e. only APID but no VPID), the vdr-plugin-xineliboutput has VDR/Setup/Plugins/xineliboutput/Audio/Visualization/Goom is enabled by default, which creates an animation modulated by the audio stream.

However, on all but one occasions I have only seen it display a few frames before grinding to a halt, which might put CRTs and Plasma displays at risk as a static image remains on the screen.

As the system is >75% idle and the animation did work nicely at least once (without any change to the settings), I cannot confirm that this is simply due to CPU-greediness as assumed in http://<email address hidden>/msg06196.html - nor that the change to settings proposed therein means any improvement.

Actually I see the same effect (slowdown after a few frames) even if selecting ridiculously low resolutions such as 51*29 which even ancient machines should be able to render (tested on an Intel Pentium 4 at 2.8GHz).

Any indications how to debug this welcome...

[TEN (launchpad-20-ten)]

Problem persists on current Hardy Heron 8.04.2 LTS, with 320*240@5fps rendering just one frame every 3 seconds approx. (however could not currently be observed to freeze entirely) - this looks a lot like a process priority issue.

[TEN (launchpad-20-ten)]

freezer from #vdr-portal on irc://www.vdr-portal.de reports this can be fixed by updating to latest xine/xineliboutput-cvs - no further details known at this time