GNOME Bugzilla – Bug 388741
Plays only until end of song against icecast using playlist
Last modified: 2006-12-26 14:43:29 UTC
Please describe the problem: GStreamer appears to stop playing when the end of a song is reached on a stream coming from an icecast2 server which is running a playlist of ogg vorbis files. Steps to reproduce: 1. Setup or find an icecast server streaming from a playlist of ogg vorbis files 2. Attempt to listen to the stream using a totem, rhythmbox, or gst-launch 3. Wait until the current song finishes Actual results: When the end of the current song is reached no more audio is played even though the server is streaming the next song. Expected results: Should continue to play and should report the new meta-data given by the server. Does this happen every time? Yes Other information: This may also occur if some other server-side modification is made, such as switching the clients to another stream. I will also attach the ices conf file (for the ices2 source client) to give an idea of how to reproduce the bug. The server configuration is pretty standard so shouldn't be a problem.
Created attachment 78812 [details] Ices2 conf file for playing a playlist of ogg music
Here's a transcript of attempting to play the stream: $ gst-launch-0.10 playbin uri=http://localhost:8000/music.ogg Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Up to that point everything looks fine, and when the song ends there is no indication of a problem, no more output, there's just no more audio. I can also see that there are 85446 bytes waiting in the TCP receive queue and it's still connected. The icecast server also shows that the client is still connected.
I think this might be a duplicate of/related to bug #320984, but can't confirm right now. Could you reproduce the bug with gst-launch and get us a debug log like this: $ export GST_DEBUG_NO_COLOR=1 $ GST_DEBUG=oggdemux:5 gst-launch-0.10 playbin uri=http://youricecastserver 2>dbg.log interrupt with control-C when it hangs $ gzip dbg.log.gz and attach the dbg.log.gz file?
Created attachment 78861 [details] debug log as requested
Thanks for the log. This does indeed look very much like the same issue as bug #320984. A solution to solve this properly is being worked on (decodebin2 etc.). The start time of the new chain doesn't look particularly right either. $ grep 'adding pad' 388741.log 0:00:01.699837000 gstoggdemux.c:1736:gst_ogg_demux_activate_chain:<oggdemux0> adding pad <'':serial_5a6a9a0f> 0:00:23.750472000 gstoggdemux.c:1736:gst_ogg_demux_activate_chain:<oggdemux0> adding pad <'':serial_3a80b139> $ grep 'new chain' 388741.log 0:00:01.552414000 gstoggdemux.c:1240:gst_ogg_chain_new:<oggdemux0> creating new chain 0x8138b38 0:00:01.552442000 gstoggdemux.c:2682:gst_ogg_demux_chain:<oggdemux0> new chain, begin time 0:00:00.000000000 0:00:23.723304000 gstoggdemux.c:1240:gst_ogg_chain_new:<oggdemux0> creating new chain 0x8138b38 0:00:23.723373000 gstoggdemux.c:2682:gst_ogg_demux_chain:<oggdemux0> new chain, begin time 5124095:32:48.468553884 *** This bug has been marked as a duplicate of 320984 ***