Version: 1.2.0 (using KDE 4.4.3) OS: Linux I have 2 directories ~/pictures and ~/pictures-2. "pictures" is a collection while "pictures-2" is a simple directory Digikam should not be aware of. However today it shows files from ~/pictures-2/screen/result directory. I remember it happened some version ago too, though at the time I thought that it was my DB corrupt. However this one is ~ 1 month or so (rescanned). Reproducible: Always Steps to Reproduce: 1. I opened ~/pictures-2/screen/result directory in Gwenview which had 45 files. 2. Opened Digikam (search tab, I believe) 3. Moved first file from "~/pictures-2/screen/result" to "~/pictures/anime/Card Captor Sakura" via Gwenview interface (from context menu). 4. Switched to Digikam, selected today. Actual Results: Digikam shows all images the one moved to "~/pictures/anime/Card Captor Sakura" and those, that remained in "~/pictures-2/screen/result". Expected Results: Digikam should in no way know what is a "~/pictures-2/screen/result". Then I tried to reproduce it. And moved another file from ~/pictures-2/screen/1 to ~/pictures. Digikam suddenly starts disk thrashing... Eats almost a whole CPU core. I had to kill it with pkill -SIGKILL digikam. Now I have "-2" folder in a My Albums/pictures in the Digikam interface... Of course there is no ~/pictures/-2 directory on disk. I have about 15k files in a collection.
This is probably the same or similar problem as #229092. Is it possible to send me your digikam4.db file? Private mail is file.
Sent. It's around 2 MB zipped.
Thanks. It seems the fix for 221155 is missing in one other method. Can you still reproduce the 100% CPU situation? In this case, please attach gdb to the process (gdb attach <PID>) and get a backtrace (bt).
SVN commit 1132813 by mwiesweg: Also fix albumRootPath() as already done with collectionLocation() for the situation of two directories where the second one starts with the path of the first (~/pictures, ~/pictures2) CCBUG: 239902 M +6 -1 collectionmanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1132813
Unfortunately, 100% CPU situation is kind of tricky to reproduce. It didn't happen this time for some reason. I'll report a new bug if I'll manage to cause any (since I wouldn't know if it is connected to this bug anyway).
Resolving as worksforme then, as you said you would report any new bug in a new report.