Bug 89821 - GStreamer engine has trouble with vorbis streams
Summary: GStreamer engine has trouble with vorbis streams
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.1-beta2
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-19 16:50 UTC by Edmondo Tommasina
Modified: 2006-06-11 12:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edmondo Tommasina 2004-09-19 16:50:39 UTC
Version:           1.1-beta2 (using KDE KDE 3.3.0)
Installed from:    Gentoo Packages
Compiler:          gcc-3.4.2 
OS:                Linux

I'm starting amarok (gstreamer plugin) from the command line to listen an icecast local streamer in the following way:
amarok http://sauron.eriadon.ch:8000/sauron.ogg

The music start to play and everything is ok until the song finishes and the next should start. At this point amarok crashes and in the console I get many similar messages:
(...)
** (process:657): CRITICAL **: file adapter.c: line 145 (gst_adapter_peek): assertion `size > 0' failed
(...)
Comment 1 Christian Muehlhaeuser 2005-01-05 06:26:22 UTC
please confirm, if it's still valid.

thanks,
muesli
Comment 2 Edmondo Tommasina 2005-01-05 08:12:49 UTC
I the last months I have updated quite a lot (see later), but a similar problem persists, but I don't see anymore the CRITICAL error in the first message. When the song finishes, the next one doesn't start (with xmms and ogg123 I don't have the problem) and the Playlist window shows a flashing and growing buffering % information. When the buffer reach 100% it starts again from 0%.

Here the new tested software configuration.
amarok            : 1.2_beta2
gstreamer         : 0.8.8
gstreamer-plugins : 0.8.5
gcc               : 3.4.3
linux-kernel      : 2.6.10

Do you have some hints how I can give you better informations?
I will try to compile everything with debugging symbols.
Comment 3 Mark Kretschmann 2005-01-06 10:33:49 UTC
Yes, known problem. GStreamer-Engine can't currently play vorbis streams, at least not properly.

This is because of a weird design issue with GStreamer, making vorbis streams fail with the "spider" autoplugger we are using. I would have to use another autoplugger, which would require quite a bit of refactoring.

If you want to, you can also make a bug report in the GStreamer bugzilla. Wishing for vorbis radio streams to work with spider. 
Comment 4 Edmondo Tommasina 2005-01-06 22:33:32 UTC
Interesting. After reading your message I studied how can I run the GStreamer pipeline from the command line. Thanks for the hint.

Short version of my answer:
Amorak is not guilty. :-) Yes, there is a problem at the GStreamer level, so I will open a bug report there.

Long version of the answer:
Even from the command line (using gnomevfssrc) the first song plays very fine but when the next song comes, just silence comes out of my boxes. No message, no nothing. Just an eternally long silence. Luckly silence is a good thing. ;-)
I get the same wrong behaviour with the "spider" autoplugger and even with the full "oggdemux ! vorbisdec ! audioconvert" pipeline. I don't think the problem is even deeper then with the "spider" autoplugger.

I tested with following 2 commands.

With spider autoplugger:
edmondo@gollum ~ $ gst-launch-0.8 gnomevfssrc location="http://192.168.1.11:8000/sauron.ogg" ! spider ! alsasink

Without spider autoplugger:
edmondo@gollum ~ $ gst-launch-0.8 gnomevfssrc location="http://192.168.1.11:8000/sauron.ogg" ! oggdemux ! vorbisdec ! audioconvert ! alsasink

Ok, now let's go open a bug by gstreamer bugzilla.
Mark, if you think it's better to close this bug report, feel free to do it. If not I will not forget it and update it when there are interesting things to write.


Comment 5 Mark Kretschmann 2005-01-06 22:52:56 UTC
I was told to use the "decodebin" autoplugger instead. It is newer and said to be more capable.

Unfortunately, it works very differently from spider, and I can't yet see how to make it work with our engine. Well, and spider works fine for everything else, so I'd rather just keep it.
Comment 6 Edmondo Tommasina 2005-01-06 23:11:57 UTC
I tested "decodebin". Thanks. Finally I have a segmentation fault to look at and do a better report to GStreamer bugzilla :-)

I'm not in the position and I don't have the know how to judge what's better to use spider or decodebin, but following link of the GStreamer documentation tells about the differences of spider and decodebin:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-components-spider.html

There is a "scary" information:
"Those internal differences are the main reason why spider is currently considered deprecated (along with the fact that it was hard to maintain)"

And a good information as well:
"Code for using spider would look almost identical to the code of decodebin"


And here just for completeness the segmentation fault:
edmondo@gollum ~ $ gst-launch-0.8 gnomevfssrc location="http://192.168.1.11:8000/sauron.ogg" ! decodebin ! alsasink
RUNNING pipeline ...

(process:21036): GLib-GObject-WARNING **: invalid uninstantiatable type `<unknown>' in cast to `GstRealPad'
(...)
Segmentation fault

... and now let's play with valgrind :-)
Comment 7 Edmondo Tommasina 2005-01-08 22:53:37 UTC
Slowly I'm understanding a bit more how to use GStreamer. The GStreamer developer (Ronald Bultje) gave me the following information:
"Chained ogg starts a new ogg stream per song, which uses new pads on the
oggdemux element. Therefore, you need a pad manager. Try playbin."

After an hour of random try and error on the command line, I found the following command and I can listen successfully my ogg-radio stream:
edmondo@gollum $ gst-launch-0.8 playbin uri="http://192.168.1.11:8000/sauron.ogg"
Comment 8 Greg Meyer 2005-02-02 05:25:41 UTC
So can this bug be closed then?
Comment 9 Edmondo Tommasina 2005-02-02 07:17:21 UTC
Yes, as I've written in comment #4 you can close the bug if you feel it's better to do so. The bug is not really amarok related, but gstreamer spider related. I used the open bug just to report more informations even on the amarok bugzilla if somebody else has the same wish/problem.
Comment 10 Mark Kretschmann 2005-02-02 10:06:09 UTC
No, please let the bug open. I intend to fix this problem eventually.
Comment 11 Mark Kretschmann 2005-03-01 18:58:39 UTC
CVS commit by markey: 

FIX: GStreamer-engine can now play vorbis radio streams properly, with full metadata support.

BUG: 89821
CCMAIL: amarok-devel@lists.sf.net


  M +2 -0      ChangeLog   1.536
  M +5 -2      src/engine/gst/gstengine.cpp   1.235


--- kdeextragear-1/amarok/ChangeLog  #1.535:1.536
@@ -5,4 +5,6 @@
 
 VERSION 1.2.2:
+  FIX: GStreamer-engine can now play vorbis radio streams properly, with
+       full metadata support. (BR 89821)
   FIX: GStreamer-engine now uses the modern "decodebin" autoplugger, which
        fixes the lag issues that some users had during crossfading.

--- kdeextragear-1/amarok/src/engine/gst/gstengine.cpp  #1.234:1.235
@@ -80,7 +80,8 @@ GstEngine::newPad_cb( GstElement*, GstPa
 
     if ( GST_PAD_IS_LINKED( audiopad ) ) {
-        debug() << "audiopad is already linked." << endl;
-        return;
+        debug() << "audiopad is already linked. Unlinking old pad." << endl;
+        gst_pad_unlink( audiopad, GST_PAD_PEER( audiopad ) );
     }
+
     gst_pad_link( pad, audiopad );
 
@@ -99,4 +100,6 @@ GstEngine::removedPad_cb( GstElement*, G
     InputPipeline* input = static_cast<InputPipeline*>( inputPipeline );
 
+    // Disconnect old signal
+    g_signal_handlers_disconnect_by_func( G_OBJECT( input->decodebin ), (void*) GstEngine::newPad_cb, input );
     // Reconnect signal
     g_signal_connect( G_OBJECT( input->decodebin ), "new-decoded-pad", G_CALLBACK( GstEngine::newPad_cb ), input );