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 345449 - [icydemux] Internet radio hangs when connecting to
[icydemux] Internet radio hangs when connecting to
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Linux
: Normal minor
: 0.10.5
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
: 370401 (view as bug list)
Depends on:
Reported: 2006-06-20 17:05 UTC by Ruben Vermeersch
Modified: 2006-11-04 10:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Description Ruben Vermeersch 2006-06-20 17:05:17 UTC
Streaming just hangs when I connect to livesets radio [1]. Why and how it does this is not really sure to me, but it seems only the playerengine hangs, not the UI.

The only odd thing about the stream seems to be this:

ICY Info: StreamTitle='[LIVE]Smartek - Elements of Techno (Kleve, Ger)[LIVE]';StreamUrl='';

Is this a banshee issue or a gstreamer issue?

Comment 1 Ruben Vermeersch 2006-09-12 10:49:09 UTC
It's a gstreamer issue:

ruben@tokyo:~ $ gst-launch-0.10 playbin uri= pipeline to PAUSED ...
Pipeline is PREROLLING ...

And that's where it hangs.
Comment 2 Michael Smith 2006-09-12 10:59:55 UTC
With gstreamer cvs (roughly up to date), this has id3demux recursively typefinding the contents as id3.
Comment 3 Tim-Philipp Müller 2006-09-12 11:22:31 UTC
Culprit seems to be icydemux clearing buffer stamps of the first buffer somehow, which leads id3demux to not read the tags and typefind the input buffer again, hence the recursion. Needs fixing in both I guess.
Comment 4 Tim-Philipp Müller 2006-09-14 11:07:12 UTC
Should be fixed now:

 2006-09-14  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/icydemux/gsticydemux.c: (gst_icydemux_reset),
        * gst/icydemux/gsticydemux.h:
          When we merge/collect multiple incoming buffers for typefinding
          purposes, keep an initial 0 offset on the first outgoing buffer
          as well (otherwise id3demux won't work right). Fixes #345449.
          Also Make buffer metadata writable before setting buffer caps.

        * tests/check/elements/icydemux.c: (typefind_succeed),
        (cleanup_icydemux), (push_data), (GST_START_TEST),
          Small test case for the above.

 2006-09-14  Tim-Philipp Müller  <tim at centricular dot net>
       * gst/apetag/gsttagdemux.c: (gst_tag_demux_chain_parse_tag):
       * gst/id3demux/gstid3demux.c: (gst_id3demux_chain):
         Don't interpret a first buffer with an offset of NONE as
         'from the middle of the stream', but only a first buffer
         that has a valid buffer offset that's non-zero (see #345449).

(you can still get recursion if upstream puts a valid non-zero offset on the first buffer though, but that would be an upstream element bug then IMHO).
Comment 5 Jonathan Matthew 2006-11-04 10:22:41 UTC
*** Bug 370401 has been marked as a duplicate of this bug. ***