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 498767 - Hangs after end of tracks since 0.10.15
Hangs after end of tracks since 0.10.15
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.15
Other Linux
: Normal major
: 0.10.16
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-11-21 15:17 UTC by Sebastian Dröge (slomo)
Modified: 2007-11-21 18:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test.py (1014 bytes, text/plain)
2007-11-21 15:18 UTC, Sebastian Dröge (slomo)
Details

Description Sebastian Dröge (slomo) 2007-11-21 15:17:31 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.
Comment 1 Sebastian Dröge (slomo) 2007-11-21 15:18:01 UTC
Created attachment 99442 [details]
test.py
Comment 2 Jan Schmidt 2007-11-21 16:58:50 UTC
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.
Comment 4 Wim Taymans 2007-11-21 18:02:32 UTC
        * 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.