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 (...)
please confirm, if it's still valid. thanks, muesli
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.
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.
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.
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.
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 :-)
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"
So can this bug be closed then?
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.
No, please let the bug open. I intend to fix this problem eventually.
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 );