Amarok scan collection _really_ memory hungry?

[Corrin Lakeland]

Hi all,
 
I have recently shifted my music onto a remote server so I can use it on
all my computers.  I initially tried SMB but am now using NFS.  When I
go into amarok and rebuild the connection, amarok consumes far more RAM
than the 1GB I have currently installed.
 
It shoots up to 6GB fairly quickly, and then slowly goes up to 9GB where
I got too impatient and killed it.  (For historical reasons, my machine
has 20GB of swap so it wasn't close to running out of memory but it
seems to actually be trying to use this memory - CPU usage is at 2%).
It had got to 2/3 of the way through my collection when I last killed
it.
 
I then tried wiping .kde/share/apps/amarok and .kde/share/config/amarok*
but restarting amarok still caused a freeze on startup ('amarok is
taking a long time to start up, maybe something has gone wrong?')  The
only way I was able to recover was with the command line --wizard which
ran the first-time wizard again.  That's got it working again, but I'd
prefer it to not break in the first place :)
 
So, I appear to have worked around it by starting again and leaving it
running overnight, but that hardly seems an easy solution.  Do people
want me to do some further investigation as to why it is happening and
if amarok can be changed? Or is it just a particularly degenerate case?
I don't think amarok should attempt to consume more than 4GB of swap at
worst - most users don't have that much swap + ram.
 
Oh, basic configuration, the music consumes about 150GB which is stored
on a USB/SMB server  - currently in USB mode, plugged into my mythtv
backend which is serving it via NFS to the frontend.  The backend also
runs mysql and has 2GB of ram. The frontend has just 1GB of ram, it runs
ubuntu feisty (Version: 2:1.4.5-0ubuntu7).  I have both mysql and
sqlite3 on the frontend but neither is currently in use.

Corrin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20070426/1acf6732/attachment.html>