GNOME Bugzilla – Bug 410278
Radio Streams Constantly Rebuffering
Last modified: 2007-02-23 21:24:31 UTC
Please describe the problem: I'm having issues when playing some streams. I don't think banshee is caching data long enough and I'm constantly re-buffering the connection. This issue arises with Real Rock 101.1 Orlando's internet stream. I'm sure direct linking to their stream isn't allowed, but this is for testing purposes. mms://a1404.l1985342944.c19853.g.lm.akamaistream.net/D/1404/19853/v0001/reflector:42944=SIMULCAST=ORLANDO-FL=activerock=wjrr101fm==-6=www.realrock1011.com=1819=WJRR-FM=WJRR-FM Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
This is not a Banshee issue. Banshee just asks GStreamer to play a URI - so this should be opened under the applicable component in GStreamer. Judging from the fact that the URI is mms://, I'm going to guess it's a WMA stream. So... Are you using the Fluendo commercial plugins, or are you using unoffical/bad/ugly GStreamer plugins? I have the Fluendo Windows Media plugins and I listened to three songs and it never rebuffered.
I'm using the good/bad/ugly plugins. This occurred on openSUSE 10.2 using the build service version and Ubuntu Feisty's 0.11.7. I assumed it was a gstreamer issue also, but totem using the gstreamer backend plays this stream fine without re-bufferring.
I'm having the same issue with Radio Paradise: http://www.radioparadise.com/musiclinks/rp_128-5.m3u I am using ugly plugins. :-) Radio Paradise played okay in previous versions. Has this bug been opened in the gstreamer world somewher?
I don't know if it's been opened in GStreamer. I will reassign this to GStreamer, but if you could do a search to be sure, that would help them. If you find anything, mark this as a duplicate of what you find. Again, the Fluendo WM plugins have no rebuffering problems that I can see.
I was unsuccessful at finding a duplicate with as wide a search as I could think of so I think it's safe to say this is unique.
Possibly related to rhythmbox bug 393150?
1) What's the gst-plugins-base version you're using? $ gst-inspect-0.10 playbin | grep Version should tell you. FWIW, the mms:// URI you provided works fine for me with CVS of things. 2) Aaron: banshee needs to set the pipeline to PAUSED/PLAYING state depending on buffering messages received on the bus. playbin can't do that itself. See gst-launch.c for details.
$ gst-inspect-0.10 playbin | grep Version Version: 0.10.10
(In reply to comment #7) > 2) Aaron: banshee needs to set the pipeline to PAUSED/PLAYING > state depending on buffering messages received on the bus. > playbin can't do that itself. See gst-launch.c for details. Thanks Tim, I'll take a look and improve our states, though I'm not sure why lacking this would actually cause rebuffering. Opening since the information was provided.
Created attachment 83188 [details] [review] Banshee patch to set pipeline states when buffering For those experiencing the problem in Banshee, please try this patch. The g_debug calls will be gone in the committed version if all else is well. Tim: does this patch look sane? I'm a bit curious as to why this is even necessary though. I would have assumed that playbin would set the state properly to reflect the buffering action.
The patch seems to resolves the issue for me. Thanks abock. :-)
> > 2) Aaron: banshee needs to set the pipeline to PAUSED/PLAYING > > state depending on buffering messages received on the bus. > > playbin can't do that itself. See gst-launch.c for details. > > Thanks Tim, I'll take a look and improve our states, though I'm not sure why > lacking this would actually cause rebuffering. Because if the application doesn't pause the pipeline while rebuffering is going on, the audio sink's clock will continue to run, so the rebuffering+decoding has to happen >realtime for it to catch up, otherwise buffers will constantly be dropped as being late. If the server sends the stream data in real time, then this will lead to constant re-buffering. If your internet connection is fast and reliable enough (and the server is too), then you are unlikely to ever run into this. > I'm a bit curious as to why this is even necessary though. I > would have assumed that playbin would set the state > properly to reflect the buffering action. There are a number of issues. One is that you can't do state changes from streaming threads, another is simply that elements shouldn't change their own state themselves. Not sure about the details, the part-buffering.txt doc in gstreamer/docs/design/ might have some more rationale.
Tim: thanks for the explanations. The reason behind the rebuffering made sense to begin with, but I was unsure why it was an application issue and not a playbin issue. The description of playbin makes sense though. I'll move this back to Banshee and commit the fix. Tim: if you see any issues in the patch, please let me know if you don't mind. Thanks!
Fix committed. Please reopen if there's still an issue.