| Summary: | "digikam.dbengine: Database is locked." when scanning for new items. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ben.huber, iwannaberich, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 6.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/kde/digikam/commit/e6e76cf0cf8b34f028511958070f98f457eef81a | Version Fixed/Implemented In: | 6.4.0 |
| Sentry Crash Report: | |||
|
Description
MarcP
2018-07-16 08:53:17 UTC
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 |