GNOME Bugzilla – Bug 498767
Hangs after end of tracks since 0.10.15
Last modified: 2007-11-21 18:02:32 UTC
Hi, quoting http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452174 After upgrading libgstreamer-plugins-base0.10-0 to the latest version, I noticed that my media player, which uses GStreamer via PyGST, would hang at the end of each song. It would not hang indefinitely, but still, for a long long while. Attached is a minimal python program that exhibits the problem: with libgstreamer-plugins-base0.10-0 0.10.14-4 it starts a new track after the previous one finishes, but with 0.10.15 it hangs. You should be able to check the difference with the files at [1], which are 1 second long each: the stops will be short, but noticeable. Use longer tracks for the effect to become more evident. [1] http://chistera.yi.org/~adeodato/tmp/2007-11-20/gstbug/ I hope you can reproduce the problem. I can confirm this, with 0.10.14 the tracks switch instantly, after upgrading (core only, plugins-base left at 0.10.15) they don't.
Created attachment 99442 [details] test.py
I can reproduce the problem using sunaudiosink on this Solaris box. The length of time before EOS is emitted increases with each new file that is played. This doesn't happen if the audiosink is set to 'fakesink sync=true', which makes me suspect baseaudiosink rather than basesink.
Some possible suspects: http://webcvs.freedesktop.org/gstreamer/gst-plugins-base/gst-libs/gst/audio/gstbaseaudiosink.c?r1=1.90&r2=1.91 together with: http://webcvs.freedesktop.org/gstreamer/gstreamer/libs/gst/base/gstbasesink.c?r1=1.186&r2=1.187
* gst-libs/gst/audio/gstbaseaudiosink.c: (gst_base_audio_sink_drain): Our EOS time contains the base_time, _wait_eos() expects a running_time so we have to subtract the base_time again before calling the function. This fixes an EOS regression where the base_time was added twice and EOS took longer and longer in certain situations. Fixes #498767.