[Digikam-devel] [digikam] [Bug 331224] Sync metadata eventually slows machine to unusable state

[Jeff Robinson]

https://bugs.kde.org/show_bug.cgi?id=331224

--- Comment #4 from Jeff Robinson <jeffnik at anecho.mb.ca> ---
(In reply to comment #3)
>  a memory leak can be very easily checkable using an external tool as htop
> for ex. Just check if memory allocated by digiKam raise progressively...
> 
> The second stage is to understand where memory is lost. this can be into
> Exiv2 shared library which process whole metadata management with file
> (outside DB of course).
> 
> If you have a suspected problem with DB, you can try to run a fresh digiKam
> from a test account on your computer. Import new image a run maintenance
> tool in same conditions.
> 
> Gilles Caulier

I created a new account and was able to have the same 22 files recognised
properly, bringing the information from the XMP files in as expected.

Going back to the original account, I took the step of renaming the existing
Digikam database and thumbnail data and restarting.

I added a local directory which was catalogued properly, including information
from the XMP sidecar for the RAW files.

I then added my networked portfolio drive (which took about 3 hours to
catalogue), and this also seems to be working properly.

I did try running the maintenance tool on this new install and the same issue
seems to occur.  Using htop I can watch the Digikam process add about 2MB of
memory usage every 3 seconds or so, with one of the cores always around 90%.

I may have been seeing two different issues with one caused by a damaged
database.  The maintenance tool problem still seems to persist for me, though.

The Exiv2 library I'm using is 0.23 from Slackware-Current, but I wouldn't know
how to go about finding out if it is the cause of a memory leak.

-- 
You are receiving this mail because:
You are the assignee for the bug.