GNOME Bugzilla – Bug 647480
Banshee uses large amounts of CPU between songs
Last modified: 2020-03-17 09:26:51 UTC
When I press "previous" or "next" song briefly Banshee uses 125% CPU on a 3.2Ghz processor. This can be observed by putting a very short (0.1 seconds) MP3 on "repeat single." Banshee will now use an average of 50% CPU constantly. It happens with every version of Banshee I have ever used up to and including the latest version from the Ubuntu daily-ppa. When testing I emptied the library so that the test MP3 was the only file in it and I disabled all plugins except for "Play Queue". I tried the same experiment with rhythmbox and it never uses more than 5% CPU even with a populated library and default set of plugins. While investigating this bug I also discovered that Banshee often crashes during the same experiment. I reported that bug at https://bugzilla.gnome.org/show_bug.cgi?id=647478 - you can find logs and the test MP3 attached there.
I forgot to mention that the high CPU usage also makes the UI unresponsive - eg opening the menu takes 2 seconds etc.
Please file the 50% CPU usage in a separate report.
Separate to what?
Separate to this bug report. It sounds like an unrelated issue to the high CPU on song-change issue, and thus should be filed separately.
It isn't. Try the experiment and you will see this. The average CPU vs min/max CPU is merely a side effect of the update rate of top. eg top -d0.1 -p `pidof banshee`
So when it's not switching songs, Banshee's CPU usage is not 50% - it's more like 0-10%?
Yes. The point is that when it switches songs it spikes at up to 200% CPU. While playing a normal length MP3 the average CPU is around 10%. Still very high for an MP3 player but as you say, that is a different issue. When playing the 0.1 second MP3, the spikes happen often enough to keep the average CPU at 50%. Or put another way, since switching songs takes a high but fixed amount of CPU, the average CPU use over time depends on how often the song is switched. Using a 0.1 second MP3 maximizes the number of song switches and therefore maximizes the effect of the bug.
Both UbuntuForums user pablouy and I were also experiencing this problem, with a similar 39 second or 40 second period after a song starts or song change when one CPU core is pegged at 100%, and the UI is largely unresponsive. The matching duration is strange, given that we have quite dissimilar hardware. pablouy's comment is in this post: http://ubuntuforums.org/archive/index.php/t-1725311.html The weird thing is that I only saw the problem the first time I ran Banshee; when I restarted it with --debug I didn't hit the problem, and subsequently without --debug it also didn't appear.
My banshee climbs in CPU usage from over 30% at the app launch, to over 140% within a few seconds. This is without even playing ANY files. WTF is going on with this program? It freezes up mu Dual-core AMD 64bit processor with 4GB DDR3 ram. I have the latest version of Banshee (2.1.0). All updeated and new and it still freezes myh computer by eating the processor over 166% peaks right now with NO media playing...Sorry, but this is absolutely stupid. Could somebody please fix this problem? Thanks
(In reply to comment #9) > My banshee climbs in CPU usage from over 30% at the app launch, to over 140% > within a few seconds. This is without even playing ANY files. WTF is going on > with this program? It freezes up mu Dual-core AMD 64bit processor with 4GB > DDR3 ram. I have the latest version of Banshee (2.1.0). All updeated and new > and it still freezes myh computer by eating the processor over 166% peaks right > now with NO media playing...Sorry, but this is absolutely stupid. > > Could somebody please fix this problem? > > Thanks That is a different issue than this bug, and one that I'm not familiar with. Please open a new bug report for it here: https://bugzilla.gnome.org/enter_bug.cgi?product=banshee.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.