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 601841 - 100% CPU usage and lockups during file playback
100% CPU usage and lockups during file playback
Status: RESOLVED DUPLICATE of bug 601897
Product: rhythmbox
Classification: Other
Component: playback
0.12.x
Other Linux
: Normal major
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-11-13 21:19 UTC by swordphsh
Modified: 2009-11-14 21:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description swordphsh 2009-11-13 21:19:17 UTC
I updated to ubuntu 9.10 on 11/8 and rhythmbox worked fine until 11/12 when the 0.12.0-ubuntu5 update was pushed. I previously had 0.12.0-ubuntu4. Now, when I play a song, Rhythmbox uses 100% and often locks up after a minute or so of playback and has to be ended or killed. I tried uninstalling completely (remove all configuration files), in addition to deleting any configuration files I could find, but the problem persists. I even tried downgrading back to the "ubuntu4" version, but it did not make a difference. It works fine under root.
Comment 1 swordphsh 2009-11-13 21:22:27 UTC
Edit: The "ubuntu4" version works, I just had to "completely remove" ubuntu5 before downgrading.
Comment 2 Jonathan Matthew 2009-11-13 21:49:34 UTC
There are no differences between 0.12.5-0ubuntu4 and 0.12.5-0ubuntu5 that could possibly account for this change in behaviour.

What exactly did you do to "completely remove" the 0.12.5-0ubuntu5 version?
Comment 3 swordphsh 2009-11-13 22:06:57 UTC
When I tried downgrading to 0.12.5-0ubuntu4, I went into synaptic, right-clicked rhythmbox, and selected "Mark for Complete Removal."

I also tried doing that and deleting any rhythmbox configuration files/folders I could find in the system, including under gconf-2, and reinstalling 0.12.5-0ubuntu5. All my settings were removed, but it still used 100% cpu. I did note, however, that it ran fine under root/sudo (just to test it out).

Are there any additional user configurations that I could try removing that may not be located in a file/folder named rhythmbox?
Comment 4 Jonathan Matthew 2009-11-13 22:49:24 UTC
I can only think of three configuration settings that would be likely to have any impact on this: whether crossfading is enabled, what plugins are enabled, and the output device configuration.  All of these are stored in gconf.
Comment 5 swordphsh 2009-11-13 22:55:19 UTC
I deleted the rhythmbox folder under ~/.gconf and I also tried disabling all plugins and never had crossfading enabled. I don't see anything about output device, but I my system default is alsa.

I just noticed, while playing music for about 30 minutes or so, it began using a lot of cpu power, but pausing/resuming fixed it.
Comment 6 Jonathan Matthew 2009-11-13 23:35:09 UTC
Modifying or deleting files under ~/.gconf is generally a bad idea.  You should use gconf-editor or gconftool-2 --recursive-unset /apps/rhythmbox to remove application settings.

Do you see similar problems in other GStreamer applications, such as totem?  Does this seem to be specific to a type of file you're playing?
Comment 7 swordphsh 2009-11-13 23:45:44 UTC
Thanks for the tip, it seems to be working now. Here's what I did:

-Marked Rhythmbox for a complete removal and applied it
-Ran "gconftool-2 --recursive-unset /apps/rhythmbox"
-Installed Rhythmbox 0.12.5-0ubuntu5

I'll report back if I encounter any further issues. Thanks for your help.
Comment 8 swordphsh 2009-11-14 21:40:54 UTC
Hi, sorry to bother you again, but the problem started back up again. I tried doing what I did yesterday to resolve it, but it does the same thing with ubuntu4 and ubuntu5 versions (100% cpu then freezes).

I installed banshee, it does the same thing, but Totem does not have the issue.
Comment 9 Jonathan Matthew 2009-11-14 21:45:37 UTC
This appears to be the same issue as bug 601897.  There's more useful information there, so I'm closing this bug as a duplicate.

*** This bug has been marked as a duplicate of bug 601897 ***