Every time digikam has to scan for new items (new pictures that have been copied to its watched folders), it takes a while to scan them. In debug view, I continuously see these messages for each new picture: [18700] digikam.dimg: "Z:/Fotos/2018-07 My Holidays/IMG_6950.JPG" : JPEG file identified [18700] digikam.dbengine: Database is locked. Waited 7000 [18700] digikam.dbengine: Database is locked. Waited 6000 [18700] digikam.dbengine: Database is locked. Waited 7250 [18700] digikam.dbengine: Database is locked. Waited 6250 [18700] digikam.dbengine: Database is locked. Waited 7500 [18700] digikam.dbengine: Database is locked. Waited 6500 [18700] digikam.dbengine: Database is locked. Waited 7750 [18700] digikam.dbengine: Database is locked. Waited 6750 [18700] digikam.dbengine: Database is locked. Waited 8000 [18700] digikam.dbengine: Database is locked. Waited 7000 [18700] digikam.dbengine: Database is locked. Waited 8250 [18700] digikam.dbengine: Database is locked. Waited 7250 [18700] digikam.dbengine: Database is locked. Waited 8500 [18700] digikam.dbengine: Database is locked. Waited 7500 [18700] digikam.dbengine: Database is locked. Waited 8750 [18700] digikam.dbengine: Database is locked. Waited 7750 [18700] digikam.dbengine: Database is locked. Waited 9000 [18700] digikam.dbengine: Database is locked. Waited 8000 [18700] digikam.dbengine: Database is locked. Waited 9250 [18700] digikam.dbengine: Database is locked. Waited 8250 [18700] digikam.dbengine: Database is locked. Waited 9500 [18700] digikam.dbengine: Database is locked. Waited 8500 [18700] digikam.dbengine: Database is locked. Waited 9750 [18700] digikam.database: Adding new item "Z:/Fotos/2018-07 My Holidays/IMG_6950.JPG" For what I see, it takes around 10 seconds to scan each new picture. Moreover, digikam's interface does not respond during that process, so for 400 new pictures, I estimate that it will take around an hour for digikam to become responsive before I can use it. The database (SQLite) is currently stored in a network share, which could certainly affect the performance, but I remember this being an issue even when the pictures and the database were stored locally. I am using the last digikam 6.0 snapshot for windows 10 64 bit.
I tried to simulate the problem with an SQlite database on a very slow USB stick. Yes, the scan of new images takes an extremely long time, over 10 seconds per image, but I can not reproduce a locked database. Can you describe how you added the images, via Windows Explorer or via digiKam? However, the problem will not be solved for us. SQlite needs this locked process and if another thread is still not finished after 10 seconds, digiKam can not change this. Combining all SQlite actions in an intermediate layer would not solve the problem either, since digiKam still stands still because it has to wait. SQlite does not belong on a remote drive, only locally, preferably on an SSD. Even on a local HDD, a locked database of 1-2 second can occur, with digiKam actions that require a lot of access. Maik
The files (a whole folder of 400 pictures) was copied using windows explorer to its destination. Is this a problem that only affects SQLite? Would changing to MySQL or another database avoid these waiting times? Tell me if you want me to run some more tests. I could try scanning from a local folder, and also using a locally stored database.
*** Bug 406228 has been marked as a duplicate of this bug. ***
In our case the database file is local. the lock error happens nevertheless.
A locked database is completely normal with SQLite. It is not possible to read and write from a SQLite database at the same time, an active write action must first be completed. Maik
But isn´t there a way not to freeze the whole interface while scanning for new items? Bug #389652 is basically a consequence of this. Ideally, you should be able to use Digikam even if it´s scanning for new items. Just like you can browse albums just fine while it´s writing metadata changes to files. I don´t know exactly how it´s been implemented, but maybe giving a higher priority to user actions rather than the background new file scan, so when in conflict, the user has priority? Like pausing for a moment the scan of a file/folder and do what the user has requested in the interface, and then resume the scanning. Or, as a last resort, tell the user that the interface won't be available during the scan. Otherwise, at least in Ubuntu, it constantly throws "Force close" messages to the user, which is not elegant.
The scanning process is a separate task that does not block the GUI. In this case it would help because of the locked database, with the digiKam database to switch to a local MySQL server. Maik
Git commit e6e76cf0cf8b34f028511958070f98f457eef81a by Maik Qualmann. Committed on 15/09/2019 at 06:47. Pushed by mqualmann into branch 'master'. less locked database during the initial scan Related: bug 389949, bug 411927 FIXED-IN: 6.4.0 M +3 -1 NEWS M +8 -4 core/libs/database/collection/collectionscanner_scan.cpp https://invent.kde.org/kde/digikam/commit/e6e76cf0cf8b34f028511958070f98f457eef81a