https://bugs.kde.org/show_bug.cgi?id=396559
Maik Qualmann <metzping...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |metzping...@gmail.com
--- Comment #1 from Maik Qualmann <metzping...@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
