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 410278 - Radio Streams Constantly Rebuffering
Radio Streams Constantly Rebuffering
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: GStreamer
0.11.7
Other All
: Normal normal
: 2.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-02-21 05:20 UTC by Craig Duquette
Modified: 2007-02-23 21:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Banshee patch to set pipeline states when buffering (3.34 KB, patch)
2007-02-23 19:52 UTC, Aaron Bockover
committed Details | Review

Description Craig Duquette 2007-02-21 05:20:38 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:
Comment 1 Aaron Bockover 2007-02-21 05:39:16 UTC
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. 
Comment 2 Craig Duquette 2007-02-21 05:56:14 UTC
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.
Comment 3 Josiah Ritchie - flickerfly 2007-02-23 16:16:23 UTC
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?
Comment 4 Aaron Bockover 2007-02-23 17:58:57 UTC
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.
Comment 5 Josiah Ritchie - flickerfly 2007-02-23 18:12:00 UTC
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.
Comment 6 Josiah Ritchie - flickerfly 2007-02-23 18:24:51 UTC
Possibly related to rhythmbox bug 393150?
Comment 7 Tim-Philipp Müller 2007-02-23 18:27:46 UTC
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.
Comment 8 Josiah Ritchie - flickerfly 2007-02-23 18:53:47 UTC
$ gst-inspect-0.10 playbin | grep Version
  Version:              0.10.10
Comment 9 Aaron Bockover 2007-02-23 19:18:59 UTC
(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.
Comment 10 Aaron Bockover 2007-02-23 19:52:32 UTC
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.
Comment 11 Josiah Ritchie - flickerfly 2007-02-23 20:06:18 UTC
The patch seems to resolves the issue for me. Thanks abock. :-)
Comment 12 Tim-Philipp Müller 2007-02-23 20:12:54 UTC
> > 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.
Comment 13 Aaron Bockover 2007-02-23 20:35:32 UTC
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!
Comment 14 Aaron Bockover 2007-02-23 21:24:31 UTC
Fix committed. Please reopen if there's still an issue.