After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 330816 - ~5s delay when chaning songs or seeking in music player
~5s delay when chaning songs or seeking in music player
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.3
Other All
: Normal major
: NONE
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-11 19:36 UTC by Markus Koller
Modified: 2006-02-26 11:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Markus Koller 2006-02-11 19:36:36 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?
Comment 1 Joe Wreschnig 2006-02-12 00:56:53 UTC
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.
Comment 2 Andy Wingo 2006-02-13 10:04:06 UTC
CCing jan -- was there anything about the basesink refactoring that could have caused this if -base wasn't upgraded with core?
Comment 3 Wim Taymans 2006-02-13 11:28:27 UTC
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?
Comment 4 Joe Wreschnig 2006-02-13 19:03:51 UTC
I've checked with -base 0.10.3 / -good 0.10.2 and it seems to be fixed.
Comment 5 Markus Koller 2006-02-26 11:28:24 UTC
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.
Comment 6 Luca Ognibene 2006-02-26 11:40:01 UTC
thanks!