Digikam seems to be re-scanning (and rebuilding) thumbnails on my pictures even though these pictures have not been touched. The pictures that seem to trigger this behavior are ones that have the same filename, but reside in different directories and are actually different pictures (digital camera reset count). Scan to rebuild fingerprints works perfectly and does not seem to have this problem.
Which version of digiKam you use ? Re-sacn is done when exactly ? Do you have used a tool just before ? Gilles Caulier
I'm using 2.5.0, but this bug has been present ever since I started using digikam back in the 1.somthing days. What I do is to select Tools->Rebuild Thumbnails, then I click on Scan. I see the progress window open and I see it rebuilding many files (maybe 100 out of 66,000). If I then immediately go and do the same thing again. It rebuild the same files over again. When I pick out a bunch of the files that are rebuilding over and over and find them on my system, then I see that each of then appears with the same name, but in different directories. They seem also to be different photos, but have the same filename because my camera had its count reset and it generates new photos that have duplicate names for photos already on my system in different folders. I don't actually know if this has anything to do with it, but that is what I noticed.
Is there a way I can collect some data to help resolve this? Maybe a list of the files that are being rebuilt and / or database logs etc?
If you open digikam and go to the individual albums showing these pictures, and watch the thumbnail of them: Does digikam also rebuild them? (when rebuilding, there's usually some output on the console from here and there) Or is it only a phenomenon of the Rebuild Thumbnails tool?
Jim, This entry still valid using digiKam 3.5.0 ? Gilles Caulier
I ran the maint->thumbnail utility and then immediately reran it. It still takes several (7 or 8) minutes to run and I can see the same thumbnails show up on the progress window. I get the same thing no matter how many times I rerun without any interviening actions. The same test using the fingerprint utility runs (slowly at first as it generates new fingerprints), then it runs immediately with no delay when run the second time. I ran digikam from a terminal window and only see a couple of messages like these below: libpng warning: Unknown iTXt compression type or method Thread::requestAbort: not running. I also had the system log window up and don't see any messages generated from digikam. I can't tell which files are being re-thumbnailed. Only that the images on the progress bar look basically the same as they flash by each time I run it. Is there a way to find out which files it is re-thumbnailing? Thanks, Jim Shipman Random observation: Version 3.5.0 seems much buggier than previous versions. I get hangs if I try to do anything while a long operation (like tagging a bunch of photos) is running and have to kill digikam manually. Also digikam still crashes without any log info, when I preview a movie file (has always done this since very early versions -- still does).
Tools->Maint->thumnails (only changed) still is rebuilding thumbnails on some files. I am not able to tell which files are being rebuilt again but I can tell from watching the thumbnail pictures as they fly past that digikam is rebuilding the same thumbnails over and over again each time I run the maint. task. Is there some way that I can get a listing of which thumbnails are being rebuilt? It would help to be able to identify some of the files that are being rebuilt each time then I could do more to find out why. This is the 4.1.0 from git release with compiled source. Jim Shipman
Hum... Do you use Sqlite or MySQL ? because here with SQlite, it work as expected... To print processed file, you can enable debug space using kdebugdialog, and run digiKam from a console. Items must be printed at processing. http://www.digikam.org/contrib Gilles Caulier
Created attachment 86864 [details] Script to start digikam with debug support Script to start digikam with debug support.
Sorry, I lost my comment when I attached the script file. I use SQLite right now, but I used to use MySQL and it had always worked fine for me. The reason I changed was because I wanted to put my database into a ram disk for performance while doing massive metadata updates and MySQL running on the same machine was slower than SQLite with a database in RAM. I'll try the kdebugdialog trick to see what I can find. I'll have to research that as I've never used that tool. Jim
I think a RAM disk is not mandatory to have good performance with SQlite. Here i use a SSD of 500Gb to host DB and photos, and it's very powerfull. I would to preserve my 16Gb or RAM to process huge photo, as >100Mpx panorama. Gilles Caulier
The problem is due to thumbs database contents is not maintained well when file are deleted. Database preserve a trace of old files. It's explained in bug #317210 Gilles Caulier *** This bug has been marked as a duplicate of bug 317210 ***
Fixed with bug #317210