Banshee uses too much CPU

Bug #396268 reported by Alistair Buxton on 2009-07-06
300
This bug affects 67 people
Affects Status Importance Assigned to Milestone
Banshee
Confirmed
Critical
banshee (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: banshee

While playing and minimized to the system tray, Banshee uses 65-70% CPU and also pushes pulseaudio CPU usage up to around 30%. Additionally, when using "next" or "previous" buttons Banshee CPU usage goes up to 150%. Importing approximately 6000 songs took over 20 minutes, although the first 3000 or so only took about 5 minutes.

System: P4 2.8 Ghz with hyperthreading, 2GB RAM

Tested with latest Banshee from Jaunty repos and also the Banshee Team PPA version.

Alistair Buxton (a-j-buxton) wrote :

Update: This problem seems to be getting worse. Banshee is now using 70% - 90% CPU, although pulseaudio usage has drop to 10% - 20%.

Hamish Downer (mishd) wrote :

I can confirm this in karmic - on opening, cpu goes through the roof for a while. Any interaction seems to take ages - even without playing music. (I mostly use it for managing podcasts).

Changed in banshee (Ubuntu):
status: New → Confirmed
Hamish Downer (mishd) wrote :

I tried moving the banshee config files (in ~/.config , ~/.cache and ~/.gconf/apps/ ) out of the way to try banshee with a clean set up, and still had this problem, so it is not related to my data.

Possible duplicates are bug #448533 and bug #440707.

Hamish Downer (mishd) wrote :

Just tried banshee in a fresh user account, and it worked fine, so why won't it work for me when I move the database around ...

On Thursday 22,October,2009 01:22 AM, Hamish Downer wrote:
> Just tried banshee in a fresh user account, and it worked fine, so why
> won't it work for me when I move the database around ...
>
Something in gconf perhaps? Or perhaps migration from old Banshee settings?

Old settings:
Gconf: /apps/banshee
Files: ~/.config/banshee

New settings:
Gconf: /apps/banshee-1
Files: ~/.config/banshee-1

If you're interested in just clearing up the issue, `gconftool-2
--recursive-unset /apps/banshee /apps/banshee-1`. Otherwise, it would be
interesting to see what's in your ~/.gconf/apps/{banshee,banshee-1} directories
for debugging purposes.

It would be even better if you messed around with the settings using
gconf-editor and figured out the setting at fault. =)

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Hamish Downer (mishd) wrote :

Vacuuming the sqlite database helped a little bit ... If anyone else wants to try this, you first install the sqlite3 package, and then (at the command line)

$ sqlite3 ~/.config/banshee-1/banshee.db "VACUUM;"

I will play with gconf soon and report back.

Hamish Downer (mishd) wrote :

I backed up .gconf/apps/banshee-1/ .config/banshee-1/ and .cache/banshee-1/ (There were no /apps/banshee or .config/banshee files on my system).

I then tried `gconftool-2 --recursive-unset /apps/banshee /apps/banshee-1` but that does not seem to have made any difference. It still takes about 5 seconds of 100% cpu before the UI updates after I click on anything.

I then tried just deleting all the files:

$ rm -r .config/banshee-1
$ rm -r .cache/banshee-1
$ rm -r .gconf/apps/banshee-1

And banshee was responsive (once it had started, ps -ef reported that there was 9 seconds of time used by banshee after starting up).

I've restored it, and it is unresponsive again. I have only 62 items in my music library. However I have 20 podcast feeds, with a total of 1699 items. I don't know if that would overly stress banshee? I would hope not.

Given that turning off all gconf settings didn't help, do you have any other ideas?

Chow Loong Jin (hyperair) wrote :

On Friday 23,October,2009 12:15 AM, Hamish Downer wrote:
> I backed up .gconf/apps/banshee-1/ .config/banshee-1/ and
> .cache/banshee-1/ (There were no /apps/banshee or .config/banshee files
> on my system).
>
> I then tried `gconftool-2 --recursive-unset /apps/banshee
> /apps/banshee-1` but that does not seem to have made any difference. It
> still takes about 5 seconds of 100% cpu before the UI updates after I
> click on anything.
>
> I then tried just deleting all the files:
>
> $ rm -r .config/banshee-1
> $ rm -r .cache/banshee-1
> $ rm -r .gconf/apps/banshee-1
>
> And banshee was responsive (once it had started, ps -ef reported that
> there was 9 seconds of time used by banshee after starting up).
>
> I've restored it, and it is unresponsive again. I have only 62 items in
> my music library. However I have 20 podcast feeds, with a total of 1699
> items. I don't know if that would overly stress banshee? I would hope
> not.
>
> Given that turning off all gconf settings didn't help, do you have any
> other ideas?
>
Well, you could check what's going on in `banshee --debug`. Also, you could try
disabling the podcasts extension and see if that helps.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Hamish Downer (mishd) wrote :

I tried 'banshee --debug' - there was no output during the periods of 100% cpu usage. I've attached the log file, but it looks pretty uninteresting to me.

Hamish Downer (mishd) wrote :

OK, it's definitely the podcast extension in my case. If I disable it then banshee is nice and snappy. But when it is on, jumping around within the podcast functionality causes 100% cpu for a bit. When it is on, jumping around in other bits is quite fast actually, but as I generally use the podcast stuff that would be why it seems slow.

Changing the view from (New Items AND All Items AND All Podcasts) to (New Items AND Downloaded AND All Podcasts) is one of the key slow operations. But given that (New Items AND All Items AND All Podcasts) is generating a list view with 1700 items, I guess this could explain the slowness ...

Is there anyway to add something like 'Show last 100' / 'Show all' option to avoid making such a big list?

Just a note about my usage - I only download a fraction of the podcasts, but I like to have them there and see what topics are covered so I can decide which ones to download. Is this a reasonable use case, or will I have to remove the podcasts that I only listen to the occasional episode of?

Hamish Downer (mishd) wrote :

Done more testing, and it's not just generating a big list view that causes slowness. (New Items AND Downloaded AND All Podcasts) is normally around 10-20 items. If in that I mark an item as old, it still takes 5 seconds of 100% cpu to do that.

Tomasz Jankowski (tomcioj) wrote :

I can confirm this bug in Ubuntu 9.10. I installed clean system and run Banshee without any old configuration. Moreover I disabled almost all plugins (I use only playback queue, file system queue, multimedia keys, CD cover fetcher and bmp detection).

After a week of banshee has suddenly started to use 90% - 100% of my processor time.

I use Banshee 1.6 Beta 2 (1.5.1) and Ubuntu 9.10. My music library counts ~2700 music files.

Alistair Buxton (a-j-buxton) wrote :

Since I reported this bug I have bought a new and much more powerful computer. After a fresh install of Karmic, Banshee is just the same.

Hamish Downer (mishd) wrote :

One thing I was wondering if is this bug is related to encrypted file
systems. My hypothesis would be that the whole of the sqlite db would
need to be re-encrypted after an update and sync, and maybe banshee
1.5.x is rather more keen on doing a sync. Or maybe it is sqlite.

So could other people experiencing this problem say whether they are
using encrypted file systems?

To start, I have experienced this with both dm_crypt and ecryptfs

Paul Ortyl (ortylp) wrote :

No encryption necessary, plain filesystem (ext3 in my case) and lots of files/podcasts registered in db.

I am almost never able to complete a single task with banshee/podcast without twice starting and killing it in the progress. Something that could be achieved in 2 minutes work takes at least five times as long. Usually after second or third (re)start banshee wont take 200% of my CPUs and lets the job to be done.

Alistair Buxton (a-j-buxton) wrote :

I do not use any encrypted FS. I can understand that SQLite is resource hungry but what about when it is just iconfied and playing an MP3?

Chow Loong Jin (hyperair) wrote :

On Saturday 09,January,2010 01:20 AM, Alistair Buxton wrote:
> I do not use any encrypted FS. I can understand that SQLite is resource
> hungry but what about when it is just iconfied and playing an MP3?
>
It shouldn't take too much CPU usage in that kind of situation, especially
because there are presumably no SQLite things going on at that time. Could you
try running Banshee in a clean user account to see if the issue persists? (Or
purge all your banshee configuration, as mentioned earlier in this bug report).
On my system, it only consumes around ~2% of an Intel Core 2 Duo and ~5% on a
Pentium 4 CPU for playing music, which I think is quite reasonable. How is the
CPU usage on your computer?

There is a slight CPU usage spike when switching songs, but that should be about it.

Those who do have an issue with CPU usage, please try identifying if it could be
a library issue or some other configuration problem. Also please test with
Banshee 1.5.2 from the Banshee Team PPA[1] and the daily git builds of Banshee
in the Banshee daily PPA[2].

[1] https://launchpad.net/~banshee-team/+archive/ppa
[2] https://launchpad.net/~banshee-team/+archive/banshee-daily

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Kyle Hotchkiss (kylehotchkiss) wrote :

I also have this problem. `banshee --debug` shows that beat detection is running. I would assume that's an intensive process, have you guys tried that?

Javier (javiergarcia77-gmail) wrote :

I also had this problem without having an encrypted file system. Deactivating the option

Edit > Preferences > Source Specific > Automatically detect BMP for all songs

did the trick. Not it's back to reasonable CPU usage.

Cuppa-Chino (hamcatcher) wrote :

with lucid beta2 64bit and banshee 1.6 only way for me to consistently have low cpu is to disable the bpm plugin

Chow Loong Jin (hyperair) wrote :

On Friday 16,April,2010 04:21 AM, Cuppa-Chino wrote:
> with lucid beta2 64bit and banshee 1.6 only way for me to consistently
> have low cpu is to disable the bpm plugin
>
The BPM Extension taking up CPU is another issue altogether, and only happens
when importing music, as it has to analyze the song to figure out the beats per
minute. An unfortunate consequence is that the computer needs to spend a lot of
processing to figure out this beats per minute for every song imported.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Developer

Dimitri John Ledkov (xnox) wrote :

Disabling podcasts and restarting banshee brought my CPU usage from 100% to reasonable values such that i can stop cooking breakfast on my laptop =)

Sigurd Gartmann (sigurdga) wrote :

For me, I think it is the Library Watcher plugin. One of my cpus get to 100% a few seconds after enabling this plugin, and it consistently drops to a total of 5-10% when I disable it. It may be something for others to try out as well. It behaves like this for normal 10.04 and the latest stable ppa: banshee-team/+archive/ppa

The upstream bug report is https://bugzilla.gnome.org/show_bug.cgi?id=617687

For my machine, the mirage similarity engine plugin was what was eating up my CPU. However this extension does not come with Banshee so I doubt that is the same thing for every one else.

Changed in banshee (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
David Hamm (davidthamm) wrote :

+1 to what Gartmann said. Banshee goes into coma for minutes at a time only to return for a brief hello. 1.6.1 in Lucid64

T Kortehisto (kortehisto) wrote :

I'm using ubuntu 10.10 beta and Banshee 1.7.5 just hogs CPU and RAM. When playing a song CPU usage varies between 120-175% and when the program is sleeping its still 60-120%. Banshee also uses all the available RAM and hangs constantly, probably because perceived lack of memory or RAM.

T Kortehisto (kortehisto) wrote :

Culprit for the massive memory and RAM usage for me might be Banshee's new tendency to scan my external hard drives for music files. I don't know if it is the reason, but I do know that before I installed Maverick beta, Banshee did not touch my external hard drives where as now it seems to be always reading data from them. And when I removed all my external hard drives from the system, the CPU & RAM usage both plummeted, CPU being only 6-8 % under stress and RAM 1/10th of what it used to be. Even if removing external hard drives solves my resource usage issue with Banshee, it is not a permanent solution as I need to be able to use them.

Changed in banshee:
importance: Unknown → Medium
status: Unknown → New
kienan vella (technogeek123-v) wrote :

ubuntu 10.04 - banshee 1.6.0

9500+ items in my library.
cpu usage before disabling BPM detection - >60% ram - 400mb+
cpu usage after disabling BPM detection - ~15% ram - 60mb

definitely an issue.

by disabling media player support (all of them - ipod, mass storage, MTP, iriver) i also managed to drop the cpu usage to ~6% and ram usage at about 45mb
i have a feeling that the mass storage plugin made the most difference out of the four.

Daniel Holm (danielholm) wrote :

I can confirm this in Maverick. Using Banshee PPA

Daniel Holm (danielholm) wrote :

Removed a lot of plugins I didn't use and the CPU got from 75% down to 12%.

antoirehew (antoirehew-uk) wrote :

Today is my first try on Banshee media player, because boredom lol, so I guess give this baby a try on my Dell 1501 on Ubuntu 10.10 Marverick.

At first start up everything look great, audio output quality is fine, only downside is the equaliser quality (really need to improve). Then I realised my cpu run 102% much higher then Rytembox player.

After googling around, found this forum, any try out those suggestion on the old post, NO luck. Then I do a check on the Extension Dialog, wondering could be all this extensions cause the cpu run in 100%. So I begin disable those extension that do not need (such as Pod cast, other media player sync etc) Waula... Banshee-1 show on Top is 15.3 % cpu utilisation.

Now I am happy

I disabled all plugins and CPU usage is now around 17% (down from ~100%), but I still consider this a bug. 17% CPU utilization for playing an MP3 is not acceptable IMO.

Changed in banshee:
status: New → Incomplete

After news that Banshee will be default for 11.04, I installed and began enjoying the app. However, within a few hours I've run into this bug. Turning off most of the extensions does seem to help it for me, but what a let down. It's hard for me to nail down which extension is giving me the most grief.

My system is an Acer Aspire 7736 w/ 4 GB of RAM, a dual-core 2.2 Ghz Intel chip, and plenty of HD space. I do have a large music library, clocking in at around 12-13,000 tracks (~80 GB).

Manu (scutifer) wrote :

Running Banshee with the --uninstalled option (with many extensions enabled) works for me. Not sure if thats ideal.

Morten Holmstrup (robotjox) wrote :

confirmed on maverick 32bit - I have a really fast computer and the podcast extension seems to freeze banshee. Also nothing special in debug.

antoirehew (antoirehew-uk) wrote :

Banshee 1.8.1 High cpu and Ram on 1Gb ram laptop with amd turion 64x2...

Prunus dulcis (prunus-dulcis) wrote :

I am having the same problem. Even when not playing anything, banshee uses 71-80% of the cpu (but only with activated BPM auto detection plugin).

Changed in banshee:
status: Incomplete → Expired
Alistair Buxton (a-j-buxton) wrote :

Changing the remote watch to the bug which is still open, rather than the one that has been closed due to lack of interest.

Note that there seems to be several issues which cause banshee to eat the CPU, not just one problem with one plugin.

Changed in banshee:
importance: Medium → Unknown
status: Expired → Unknown
Changed in banshee:
importance: Unknown → Critical
status: Unknown → Confirmed
Alistair Buxton (a-j-buxton) wrote :

Been doing some more testing today, and I have a testcase:

1. Completely clear out the banshee library and config:

rm -rf ~/.config/banshee-1
rm -rf ~/.gconf/apps/banshee-1
rm -rf ~/.cache/banshee-1

2. Start up banshee (it should be like the first time) and turn off all plugins except Play Queue.

3. Import a specially crafted MP3 which is 0.1 seconds long.

4. Set Playback->Repeat->Repeat Single

5. Play the MP3

Result: Banshee CPU usage swings wildly between 0 and 125%, the UI becomes slow and unresponsive, virtual memory usage increases by 8mb per second, and while I was writing this, it crashed.

Alistair Buxton (a-j-buxton) wrote :

High CPU use also observed with Banshee 2.0 from the daily PPA.

FWIW I tried the same thing with rhythmbox and it never uses more than 5% CPU - which just happens to be the same amount of CPU that Banshee uses while idling with all plugins disabled.

Alistair Buxton (a-j-buxton) wrote :

CPU usage on "next song" reported upstream here: https://bugzilla.gnome.org/show_bug.cgi?id=647480

(I'm not sure how to add multiple watches to a bug)

molecule-eye (niburu1) wrote :

Observing unusually high CPU usage of Banshee 2.0 (Natty repos) with internet features and most plugins disabled. For what it's worth, Rhythmbox has considerably lower CPU usage.

Patrick Scott (patrickscott52) wrote :

In my case CPU usage jumps to an average to 60 - 90 percent usage on both cores in the Gnome System Monitor "Resource" tab as soon as Banshee is started on 11.04. What is interesting though, is that on the Process tab of the System Monitor, Banshee registers as only using 1 - 5 percent. Also when I close Banshee, the CPU usage does not drop, the only way to bring down my CPU is to Shut down the system, however, when I do this I get a "File Manager" is not responding dialog. In my case it seems that Banshee isn't playing nice with nautilus on natty, one thing of note is that I have my music stored in a separate ntfs partition and not in the home directory.

Ubuntu "Natty" Beta 2 - 11.04 (x64 bit) - Banshee 2.0

Toby Smithe (tsmithe) wrote :

Disabling BPM detection sorted it for me here, too.

Andreas Ringlstetter (ext3h) wrote :

Same problem here, CPU frequently jumps up to 200% while banshee is running. banshee itself only consumes only ~5% (still inacceptable for just decoding a mp3 file!), but it causes pulseaudio to consume 100-150% cpu sometimes, rendering the whole system (including nautilus and ALL processes which connect to pulseaudio) unresponsable.

Same problem also occures with rhythmbox, so it looks more like a bug in ubuntus pulseaudio integration.

sgage@tds.net (sgage) wrote :

I am experiencing the cpu runaway with banshee as well (running oneiric). I have not noticed it with rhythmbox, but will see if I can get it to exhibit the same symptom.

Andrei Dziahel (develop7) wrote :

Banshee is paused now, but CPU usage still is 10-20%. Sorry to say than, but it's unacceptable.

Toby Dimmick (tobydimmick) wrote :

Still getting this on 2.1.0, worse than in previous versions. CPU at around 150% for 10 seconds or more after each song skip.

Woonjas (woonjas) wrote :

Same problem here on 2.0.1 in clean install 64-bit Natty on Dell e6520.
Since this has been around since 09, why did they decide to include this in Natty instead of Rhythmbox?

chopstickkk (saintidle) wrote :

Same problem here. Won't even play audio smoothly there are dropouts every now and again even tried disabling all the suggestions above. Really annoying as it would be an amazing player and I really like the cover art downloading and the context pane for internet options.

What a shame. Get your act together Banshee and I might take you back.

Chow Loong Jin (hyperair) wrote :

Dropouts in my experience has been a pulseaudio issue when the system is under load.

Konstantin Läufer (laufer) wrote :

In my opinion, Banshee has come a long way since I last tried. Great work! It imported my somewhat large collection fine and worked for several hours on building the database, adjusting file and folder names, etc.

In addition to BPM detection, I have found the following extensions to cause Banshee to use at least 100% of one of two available cores:

- Clutterflow
- Mirage

Once these extensions are unchecked, Banshee hogs neither CPU nor IO. This is a huge relief! (I uninstalled both.)

Disabling podcast extension worked for me =D

How does the launchpad works, will someone debug the podcast extension? What if I want to use it?

Si Dedman (si-dedman) wrote :

Dusting this old thread off, is anyone aware whether the podcast problem has been fixed?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.