GNOME Bugzilla – Bug 573319
Initial collection indexing uses too much CPU
Last modified: 2009-07-06 20:14:56 UTC
Please describe the problem: I just installed Banshee so I had to do a full indexing of my collection. The process lasted for about 6 minutes and something, during which CPU stayed mostly above 100%, and it went as high as (approximately) 156%. CPU temperature went as high as 70.9C, which is not within safe operation bounds for my CPU (a Pentium D 2.80 GHz processor). I don't have the Mirage plugin installed, and I have the "Disable features requiring Internet access" preference ticked, so it didn't download cover art for albums (from previous experience, downloading cover art drives CPU usage, and core temperature, even higher). My collection is composed of 6425 files. I attach a screen log of the banshee run while indexing, although it doesn't seem to show any interesting information. Please let me know if you need any other information. Rescanning the whole collection after initial indexing is as resource intensive as the first scan, but it seems to take less time. This was tested with Banshee 1.4.2 installed from the official Ubuntu Jaunty Jackalope (9.04, currently in alpha status) repositories. Automatically generated version information for dependencies is available here: http://launchpadlibrarian.net/23157065/Dependencies.txt Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 129609 [details] Screen log
Tommaso, thanks for your bug report. The screen log doesn't seem to show the indexing process, as it's just 2 seconds long. Could you try to attach a new log? Thanks.
Andrés, the screen log is actually about 7 minutes long, as the output of date shows. I started the indexing process right after starting Banshee, and exited Banshee as soon as the indexing ended. Dunring this time, no information at all was written to the terminal. That's why I added a date command at the end. I've repeated the indexing process a few times, and no information is ever written to the terminal during the actual indexing.
Try the --debug option: $ banshee-1 --debug
(In reply to comment #3) > the screen log is actually about 7 minutes long, as the output of date shows. I Oh yeah sorry, I don't know how I got confused looking at the log. Try what Alex suggests, and tell us the version of Mono you're using (by pursuing 'mono --version') on a console.
Created attachment 129714 [details] Screen log with mono --version and banshee --debug I have a new log with --debug which is much more verbose, but again nothing was printed to the terminal during the indexing process. This is a collection rescan. If you are interested and can tell me how to reset my collection I will try a new initial scan for you (I managed to do that, but I don't remember how I did it). Mono is 2.0.1, again from the official Ubuntu Jaunty Jackalope repositories. The attached screen log has the full output of mono --version right at the beginning.
To do a new initial scan, you can remove your banshee database file (make a backup !). It's ~/.config/banshee-1/banshee.db. After that, banshee's library will be empty. Importing or rescanning are intensive processes, and banshee is going to use a lot of CPU and disk. An initial import of about 2000 tracks took 45 seconds on my system, with a Core2 Duo CPU 2.53GHz and a rather fast disk.
What Bertrand says is true; work is going to take time and CPU. Also, there are also some post-1.4.2 indexing fixes that will be released in 1.4.3. Tommaso, any chance of running SVN trunk to see if your issue is fixed?
(In reply to comment #8) > What Bertrand says is true; work is going to take time and CPU. Also, there are > also some post-1.4.2 indexing fixes that will be released in 1.4.3. Tommaso, > any chance of running SVN trunk to see if your issue is fixed? > It depends on how complicated it is to compile it, but I think I can manage to do that if you please post a link to the instructions. BTW, I am not complaining about time taken, but about CPU usage and the consequent overheating. Currently, Banshee can harm my system. Also, I know the comparison is neither valid nor fear, but of all the players I have tried, Banshee is the only one to take this much processor AND time to index my collection on my hardware.
You can find some instructions on how to compile SVN trunk at http://banshee-project.org/download/development/ If your CPU overheats when it's working at full capacity for several minutes, I think there's a problem with your hardware setup. I can't see how any harm could be blamed on software. It would be interesting to have some figures about importing with other players, as a comparison. Ideas and suggestions on optimizing the import and rescan are of course welcome !
Sorry for the time it took me to come back to you. I tested a new import from scratch using the 1.5.0 release from the Ubuntu PPA, and CPU usage is gone down to 75%-105%, while the import still took about 6 minutes. This looks much saner. I run a comparison with Rythmbox by renaming Rythmbox DB file and forcing a new total import. I found out that Rythmbox performance seems to be aligned with Banshee overall (it used a little less CPU and took a little more time to complete), BUT after just 2 minutes the whole collection was showing in the library and the user interface was at rest. I believe Rythmbox does the import in two phases, quickly scanning the least it needs to populate the interface and then visiting each file again -- which is a clever way to look blazingly fast! I think the performance problem I reported can be deemed closed. I also hope you will consider, as a future improvement, to implement a scanning strategy similar to the one used by Rhythmbox. Please let me know if you wish me to tear a separate wishlist bug for this.
(In reply to comment #11) > I think the performance problem I reported can be deemed closed. Closing it then. > I also hope > you will consider, as a future improvement, to implement a scanning strategy > similar to the one used by Rhythmbox. Please let me know if you wish me to tear > a separate wishlist bug for this. > Sure, feel free to open a new bug for this.