GNOME Bugzilla – Bug 163351
Rhythmbox/Gstreamer stops playing, starts using 100% CPU, and needs to be killed, on some OGG and Flac files.
Last modified: 2005-11-30 10:56:53 UTC
Steps to reproduce: 1. Wait until Rhythmbox hits one of the Oggs and that's all she wrote. 2. 3. Stack trace: Don't have. Other information: I don't know if this is Rhythmbox or GStreamer related. I've got about 600 CDs ripped to FLAC and OGG Vorbis. I use the Vorbis files in Rhythmbox. A couple times of day, the music stops playing and one of two cases will be true: Case 1. Processor (P4 HT) will be at 50% (probably due to HT that it isn't 100%) and no music will be playing. Selecting "Next" in Rhythmbox moves to next song and all is fine. Case 2. This one is almost the same, but with a difference. Again, music stops playing. In this case, CPU is at 100% and Rhythmbox will not respond at all. I then kill it and restart it. I can find which Oggs are doing #1 above pretty easily but case #2 is harder as the Rhythmbox window will not "repaint" so I can see which song is locked. I guess I could leave it running all night with it in the foreground if you'd like. I'm perfectly willing to provide an Ogg that causes the problem but you may not care for the song. ;)
Please provide one such ogg and one such flac file for testing. We can arrange FTP for you if required (ask on IRC).
My bad, I sent an email to Ronald with a link to a couple of stack traces and an ogg vorbis song that is a problem. The ogg file is too big for bugzilla to accept as an attachment. I've got DSL and my address can change, but until it does: http://216.170.205.75/undun.ogg Is a file that causes 50% cpu and no play. The music stops, the rhythmbox time slider keeps going. A stack trace of rhythmbox right after it stops playing and eating CPU is: http://216.170.205.75/strace.txt Trace at end of song: http://216.170.205.75/strace_end.txt In this particular case, once the song ends, it will keep eating 50% CPU perpetually. Putting mouse over the musical note in the panel shows the song is at 29 minutes of a 3 minute song. It will keep going until I stop it. Previous versions of GStreamer/Rhythmbox used to pop up a "lost synch" message when they hit these songs. Again, sorry for the noise. Ronald has screen shots and stack traces and that ogg. I'll update the bug when it hits one of the song that triggers the other case (100% CPU). With stack trace.
Added the above as Stephane LOEUILLET changed bug status from UNCONFIRMED to NEEDINFO.
Sorry, forgot to add remark here. I tried the song in Totem and cannot reproduce anything. Now, this might be related to something Christophe showed me yesterday... Christophe, could the EOS problem you showed me be related to this, or doesn't Rhythmbox use that yet?
joseph, the songs you gave me do not reproduce the issue. Can you give me another collection of songs (2-3) that reproduce the issue when those are together in a playlist? Also, with those songs, does the problem exist only in rhythmbox or also in other apps (totem)?
This was occurring on two different machines. Both machines have completely different hardware so it wasn't machine related. Both machines are on Fedora Core 3. About 3 weeks ago the problem changed for the better. Previously two situations could occur: 50% CPU but hitting "next" in Rhythmbox would move to the next song and things would be fine. In other cases 100% CPU would be seen and Rhythmbox would be unresponsive and it would have to be killed. Both machines do "autoupdate" via YUM and something changed. Now there is only one situation: 100% CPU but hitting "next" moves to the next song and CPU goes back to normal. This is perfectly acceptable behaviour for flaky oggs and flacs. Some of the CDs were scratched and I've noticed it's generally oggs and flacs from them CDs. Not having to "kill" Rhythmbox is much better. It's likely that the change from from 50% to 100% cpu is because the machine started in non-smp mode (Hyperthreading). I'll boot to smp this weekend and see if that is the case. The machine has not locked up Rhythmbox in 3 weeks now. That is a big change as it would lock up Rhythmbox daily before. As it currently exists it's no longer a bug to me. Having to kill Rhythmbox when it hit bad Oggs was a bug. Just having to "next" past them if fine. Cheers.
It's back. With an interesting data point. The problem completely disappeared and I thought maybe an update fixed it. On that I was correct but it wasn't an update to either GStreamer or Rhythmbox. I had the machine running an SMP kernel (it has hyperthreading). When it automatically downloaded a new kernel it set priority to booting the non-SMP kernel. I've been running non-SMP for some months and not had any problems. I switched grub to boot SMP yesterday and the problem came back. So the problem only exists when one is running the smp kernels. For now I've switched back to non-SMP.
Very interesting. Well I would suggest that GStreamer 0.8 has known threading issues, and that all kinds of issues could cause the timings to work out so that it sucks, especially if the pipeline errored out very quickly after going to PLAYING. GStreamer 0.10 (to be released in... 5 days!) does a *lot* better with threading. I'm closing this bug as obsolete, because there's really nothing we can do to fix this problem on 0.8, but on 0.10 it should work fine.