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 523646 - [Last.fm] Taking CPU and leaking memory
[Last.fm] Taking CPU and leaking memory
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Other Extensions
git master
Other Linux
: Normal major
: 0.99.1
Assigned To: Banshee Maintainers
Banshee Maintainers
: 524984 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-03-20 22:26 UTC by Michael Monreal
Modified: 2008-04-29 17:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
System Monitor Screenshot (15.00 KB, image/png)
2008-03-21 10:30 UTC, Michael Monreal 		Details

Description Michael Monreal 2008-03-20 22:26:13 UTC 
There's something strange happening with the last.fm extension on trunk. After starting banshee, it takes about 38mb ram and ~0% CPU. Now, if I just switch to the last.fm source (neighborhood) and back to the library again (not playing anything) the CPU is constantly at 25-40% and the banshee process grows very quickly, about 100k every second.
Comment 1 Michael Monreal 2008-03-20 22:29:15 UTC 
Running with mono 1.2.6 btw
Comment 2 Andrew Conkling 2008-03-21 02:07:44 UTC 
Same thing happens if you switch to the Recommended station too. The CPU seems to spike while those sources are active, but then still idles high on the Library.
Comment 3 Michael Monreal 2008-03-21 08:44:40 UTC 
When first switching to a last.fm station the CPU usage is about 5-10% for me, which is still too much but less then what I see when switching back to the library (25-40%).

The memory consumption grows as soon as I switch to the last.fm source (no need to switch back to the library).

When switching back from last.fm to the queue or an empty playlist the CPU usage is lower, around 7% (still much too high).
Comment 4 Michael Monreal 2008-03-21 10:30:21 UTC 
Created attachment 107731 [details]
System Monitor Screenshot

This is after running for a bit over an hour without any playback. After about 60min the process didn't seem to grow anymore so I openend the recommendations view and changed back to the library, and it started to grow again.
Comment 5 Gabriel Burt 2008-03-29 19:12:29 UTC 
*** Bug 524984 has been marked as a duplicate of this bug. ***
Comment 6 Sandy Armstrong 2008-04-09 21:32:02 UTC 
The DAAP extension exhibits similar memory growth.  Should I file that separately or are they both caused by something lower in the stack?
Comment 7 Gabriel Burt 2008-04-29 17:34:06 UTC 
Fixed in svn.  The bug was caused by the status messages that Last.fm (and maybe DAAP?) use to communicate with the user - if they had the spinner image, it kept firing animation events even after it should have been hidden.