GNOME Bugzilla – Bug 330816
~5s delay when chaning songs or seeking in music player
Last modified: 2006-02-26 11:40:01 UTC
Please describe the problem: I'm using the Quodlibet music player, and when I updated to libgstreamer0.10 0.10.3 from 0.10.2 yesterday, the UI started to hang for up to 5 seconds when changing the song, seeking, or pausing/unpausing, while the music continued playing. I don't have any other apps which use GStreamer 0.10, but I was able to fix the problem by downgrading to 0.10.2, so it looks like it's definetely a problem with GStreamer. The problem happens both using alsasink and osssink. Steps to reproduce: 1. Install libgstreamer version 0.10.3 and the latest version of Quodlibet, or probably any other music player using GStreamer 0.10 2. Change the song, seek, pause/unpause Actual results: When changing songs: The UI hangs and the old song continues playing for upto 5 seconds, then the next song starts and the UI is responding again. Expected results: The next song should start immediately (or in a reasonable time) Does this happen every time? The delay varies between 1 to 7-8 seconds, but most of the time (I'd say 95%) it's around 5 seconds. Other information: I'm using Debian sid with mostly up-to-date versions of all packages. Here are the version of gstreamer-relevant packages: libgstreamer0.10-0 0.10.3-1 libgstreamer-plugins-base0.10-0 0.10.2-2 gstreamer0.10-plugins-base 0.10.2-2 gstreamer0.10-plugins-base-apps 0.10.2-2 gstreamer0.10-plugins-good 0.10.1-2 gstreamer0.10-plugins-ugly 0.10.1-1 gstreamer0.10-alsa 0.10.2-2 Could it be an incompatibility between the 0.10.3 libgstreamer and the 0.10.2 plugins?
I can confirm this with the same versions, Debian sid, for both Oggs and MP3s, with both Quod Libet and Rhythmbox. It takes longer for MP3s (~5 seconds) but even Oggs take 2-3 seconds usually. There is nothing odd displayed on LEVEL_MESSAGE.
CCing jan -- was there anything about the basesink refactoring that could have caused this if -base wasn't upgraded with core?
yeah, refactoring of basesink caused this regression, the reason being that baseaudiosink does not do anything when PAUSE is called on it so basesink waits for it to leave the render method, that potentially takes some time. can you recheck with gst-plugins-base 0.10.3?
I've checked with -base 0.10.3 / -good 0.10.2 and it seems to be fixed.
Same here, the latest packages in Debian sid work fine now (libgstreamer0.10 0.10.3, -base 0.10.3 and -good 0.10.2), so you may close this bug.
thanks!