GNOME Bugzilla – Bug 318749
Rhythmbox buffers forever with 100% cpu use
Last modified: 2008-06-03 17:39:24 UTC
Please describe the problem: When I try to play a pls from a danish radiochannel like: http://www.dr.dk/netradio/Metafiler/PLS/DR_P3_128.pls Rhythmbox shows a Buffering statusbar down in the right corner, and uses 100% cpu. It stays like this forever, and plays no music. If I rip some of the stream with mplayer, and ask rhythmbox to play it, it works fine. Steps to reproduce: 1. Try to play the stream or another from http://www.dr.dk/netradio/html/afspillere/03.shtml with rhythmbox Actual results: Buffers with 100% cpu use forever Expected results: To buffer in a pair of seconds, and then play the music. Does this happen every time? Jep Other information:
Could you get a backtrace of where it if spending the time while use 100% cpu? The easiest method is as follows (if you have gdb installed): 1) open a terminal 2) enter "gdb rhythmbox", followed by "run" 3) try to play the station, and wait until it starts using 100% cpui 4) go back to the terminal, type control-C, and then enter "thread apply all bt" 5) copy what it print out, and post it here Also, what version of gstreamer and gst-plugins do you have installed?
Uhm, it seams that after run, I get: [New Thread -1253278800 (LWP 14925)] (no debugging symbols found) Program received signal SIG33, Real-time event 33. [Switching to Thread -1242723408 (LWP 14923)] 0x0032b402 in __kernel_vsyscall () (gdb) and rhythmbox doesn't start. I've got gstreamer-0.8.10-1 and gstreamer-plugins-0.8.8-9
Quoting a message sent to the mailing list by Bastien some time ago: « Please put handle SIG33 nostop noprint in your ~/.gdbinit to prevent gdb from stopping on real-time events. Then regenerate the backtrace. I think here it didn't stop where the error happened. »
Super, here you are:
+ Trace 63518
Thread 8 (Thread -1265689680 (LWP 30654))
I just found out, that totem also buffers with 100% cpu when playing one of these pls files. Dunno if you need it. Here is the "(gdb) thread apply all bt" output:
+ Trace 63536
Thread 3 (Thread -1213178960 (LWP 7265))
Since it's occurring with totem as well it's a gstreamer bug, so I'm re-assigning. A lot of crasher bugs have been fixed in later versions of gst-plugins, so it may have already been fixed - however I can't check with 0.8.11 because I can't get WMA media to play.
The issue with this stream seems to be that the playlist parser isn't able to 'dive' into the playlist properly. With Totem I notice it 'stops' at the first layers instead of drilling down. Adding Bastien to the cc list
I wonder who was crazy enough to set that up. A .pls file, pointing to ASF reference files, pointing to mms streams. $ ./test-parser http://www.dr.dk/netradio/Metafiler/PLS/DR_P3_128.pls ###################### parsing ################ added URI 'mmsh://wmscr1.dr.dk/e02ch03m?wmcontentbitrate=300000/.wma&MSWMExt=.asf' with title 'empty' added URI 'mmsh://wmscr2.dr.dk/e02ch03m?wmcontentbitrate=300000/.wma&MSWMExt=.asf' with title 'empty' added URI 'mmsh://wmsc.dr.dk/e02ch03m?wmcontentbitrate=300000/.wma&MSWMExt=.asf' with title 'empty' Still, GStreamer shouldn't spin, and eat the CPU... 2006-02-06 Bastien Nocera <hadess@hadess.net> * src/plparse/test-parser.c: (entry_added), (test_parsing): Also print the genre of the URI, if available, and make parsing faster using an idle, instead of a timeout * src/plparse/totem-pl-parser.c: (totem_pl_parser_add_pls_with_contents): try to parse further inside .pls playlists to work around broken setups (Closes: #318749)
ok, julien fixed some stream selection stuff so the streams work with GStreamer 0.10 now. There is still the issue of Totem not being very smart about radio playlists, but I have another bug open for that.
Mass-move from totem to totem-pl-parser. You can remove all messages by searching for this comment.