Bug 389652 - Interface freezes during initial scan
Summary: Interface freezes during initial scan
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Scan (show other bugs)
Version: 6.1.0
Platform: Microsoft Windows Microsoft Windows
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-30 18:28 UTC by MarcP
Modified: 2020-08-28 11:07 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.4.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2018-01-30 18:28:40 UTC
This is one of the main problems I've found while using Digikam. The interface is not usable while it scans for new files and folders. It can be used intermittently for a few seconds until it just freezes (in ubuntu, it becomes grey), and this happens until the scan finishes (which may take hours or days). 

My pictures are stored in a network shared folder that I access via wifi, so this is most likely an effect of a low network speed (My files transfer at about 3-4MB/s betwee my computer and the NAS). 

I used to use Picasa, a great piece of software that is currently unmaintained. Even if scanning a library containing dozens of thousands of pictures over the network can be slow, Picasa never slows down and let you see/edit the already scanned folders while scanning for changes in the background. I think Digikam should use a similar approach and let you use the program even during a scan.

I can confirm this behavior happens both in Linux (Ubuntu 16.04.3 LTS) and Windows 10 (64bit), using digikam 5.8.0.
Comment 1 caulier.gilles 2018-08-28 19:10:23 UTC
The Windows installer have been recompiled with last changes from source code and is available here for testing :

https://files.kde.org/digikam/

Take a care : it's a beta release. Make a database backup before to test.

Gilles Caulier
Comment 2 MarcP 2018-08-28 19:55:08 UTC
Thank you, I will try the new beta and report if there are any changes in this regard.
Comment 3 caulier.gilles 2019-03-09 08:26:34 UTC
IWBR,

6.0.0 i officially released, but i propose to test with current 6.1.0 pre-release installer where a lots of improvements have been included.

File is here : https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier
Comment 4 MarcP 2019-03-09 18:20:11 UTC
Thanks. For some reason the last appimage is not working right now (bug #405233), but since I'm connecting through a VPN to my picture library, I am also experiencing bug #405235, which may interfere with what we are trying to test in this one.

I'll report back when I am under more favorable conditions, in a few weeks.
Comment 5 MarcP 2019-03-22 02:21:35 UTC
This behavior still persists. During the initial scan, you cannot browse other albums/folders. In the command line, I see a bunch of "Database is locked."

It would be great if one could browse the existing albums while the scan for new items is performed in the background.

PS: in this specific case, the pictures are in a NAS, but the database is stored locally in a SSD drive.

e.g.:

Digikam::BdEngineBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 5250
Digikam::BdEngineBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 6750
Digikam::BdEngineBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 5500
Digikam::BdEngineBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 7000
Digikam::BdEngineBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 5750
Digikam::BdEngineBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 7250
Comment 6 MarcP 2019-04-26 21:30:24 UTC
I wanted to update the issue.

Not only the interface is not responsive during the initial scan, but it many cases it also throws constant "no responding" messages under Gnome. It looks like this: https://i.imgur.com/3ELo8Qo.png (source: https://www.reddit.com/r/linuxquestions/comments/8zzhw5/disable_gnome_not_responding_box/ )

When the "program is not responding" message is present, most of the operating system freezes, not responding to mouse clicks. If you click on "Wait", it will reappear 5 or 10 seconds later. Basically the computer can't be used during that time, which usually takes a few minutes.

This is not something exclusive to Digikam, but for any program whose interface stops responding for a while, where the desktop environment things there is something wrong with it.

If I am not mistaken, in Windows 10 something similar happens, where the operating system things the program is not responding and asking to force close it.
Comment 7 Maik Qualmann 2019-09-15 06:48:12 UTC
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
Comment 8 MarcP 2020-08-28 10:18:18 UTC
Hello again,

I would like to reopen this issue.

I experienced this again in the 7.0.0 stable version on a macbook with MacOS Catalina (but also in Ubuntu some days ago). During the initial scan, while exploring for new pictures (less than 100) on a NAS, the interface was completely frozen, showing the spinning "beach ball" icon, and indicating that digiKam was "Not responding" in MacOS's task manager.

The interface responded briefly after each new file that was added (~10MB each, since they were in PNG format), but became immediately irresponsible again.

I think this should not happen. A regular user might thing that the program has crashed and try to force close it. The interface could provide more feedback on what digiKam is doing at that moment (showing which file is importing, how many files are left, etc. instead of a simple % bar, Bug #389868). Ideally, the interface should never freeze, so maybe there could be some way of separating the import process from the main interface so one doesn't block the other?
Comment 9 Maik Qualmann 2020-08-28 11:02:12 UTC
The problem is specific to macOS.
We leave the older bug closed and continue here: Bug 420334

Maik
Comment 10 MarcP 2020-08-28 11:07:00 UTC
Oh, sorry, I was not aware of that other bug report.