Digikam 8.2 scanning for new entries very slow

I have installed Digikam 8.2 as appimage on Ubuntu 22.04.
Compared to Digikam 8.1 the scanning for new entries when starting Digikam slowed down very much (51 seconds for Digikam 8.1 versus >20 minutes for version 8.2).
The database is on a local SSD and the photos are on a NAS. This setup worked fine with previous versions.
Has anybody similar problems?

2 Likes

Hello, I’ve nearly the same setup on Xubuntu 22.04: database on local ssd but my photos reside on a local harddisk. I haven’t noticed any speed changes between the Digikam appimages 7.10, 8.0, 8.1 or 8.2.

In Digikam settings - Miscellaneous - Behaviour I have checked Scan for new items at startup (makes startup slower) and Fast scan. Detect faces is unchecked, as is the fourth option (obsolete things).

Hello Paul

Thank you. To set “fast scan” resolved the issue.

Gerd

I have the same issue with 8.2 taking much longer to scan for new files (around 5 min now, compared to a few seconds in previous versions; everything on local SSD).

Is the slow scan a new feature in 8.2 and previously it always did the fast one? I just want to understand what changed that it takes so much longer now.

As mentioned before with “fast scan” switched off scanning in Digikam 8.2 takes too long. The duration is >20 min. With 140’000 photos the collection is quite big.
For the same task 8.1 takes less than a minute.
Unfortunately, with “fast scan” switched on, there seems to be an other problem.
When adding new photos it takes forever until the new photos are listed in Digikam.
This makes 8.2 essentially unusable.
I’m using SQLite with Digikam.

Hello, strange. Today I added a bunch of photos to my hd and they were immediately (some seconds) available in DK 8.3 (a nightly build). 8.3 is as fast as 8.2 or 8.1 or 8.0, at least on my 10 yeas old pc.

Under Database Settings in Configure Digikam, there’s a note: “A remote file system such as NFS, cannot be used here. For performance reasons, it is also recommended not to use network storage media.”

So perhaps your NAS is the bottleneck?

I’m not using a NAS, everything is on a local SSD in my case. So that can’t be the only reason.

I’m sorry, I mentioned the NAS in a reply to @Gerd (that was not clear indeed).

Felix, what OS are you using?

Here’s a link to a very recent discussion on kde.org about slow scanning of new photos.

https://mail.kde.org/pipermail/digikam-users/2023-December/035674.html

To my understanding a NAS or a remote file system can not be used to store the database. That is quite understandable and the reason why I have the database on a local SSD. However, there is no statement that the photo collection itself cannot be stored on a NAS. In contrary, there is a statement that remote file systems can be used.

Ubuntu 22.04. And since it might matter: I’m using the appimage release of digikam.

Hmm, same here (Xubuntu 22.04, DK appimages as well) and no speed problems at all.

I found another thread on the slowness of Digikam, one suggests to store metadata in the database and not in the images.

https://mail.kde.org/pipermail/digikam-users/2023-November/035564.html

Meanwhile I have performed database cleaning (Tools → Maintenance) with no effect at all. “Find new items” still takes far too long.
I’m not storing metadata in the image files. Besides the database Digikam is also storing the metadata in the .xmp sidecar files. However, I assume this is not the root cause for the issue.

Just opened a new bug ticket on this topic at: 478674 – Find new items at startup very slow

@luator: It might help to add your findings and configuration to the bug ticket.

It seems the cause of the problem has been identified.
Cf.: 478674 – Find new items at startup very slow

I’m just testing now. It will take some time.

Progress !!

I have finished the test successfully. Instead of >40 min. the scan takes now <30 sec.

Here is the solution provided by Maik Qualmann (478674 – Find new items at startup very slow):

I think I know the problem, files with sidecar keep getting rescanned due to a small change in digiKam-8.2.0. This was the change:

fix sidecar check as depend on the update timestamp option (4cfbcbdc) · Commits · Graphics / digiKam · GitLab

However, I forgot to make this change in the item scanner itself, so the modification date is not updated.
As a test, you can change the option in the metadata settings for timestamp updating. The first start will be slow, then the following ones will be faster again.

Depending on the time stamp update setting, the scanning speed has always been slightly different.

Maik

1 Like

Awesome! I just had time to look into it again now. I enabled the “Update file modification timestamp when files are modified” setting (which I feel should be enabled anyway…) and this indeed fixed the issue. It’s even much faster than in the past now (< 1s).

Thanks a lot!

I just downloaded and tested the new appimage V8.3. With “Fast scan” and “Update file modification timestamp…” switched off the scan takes 43 seconds (collection size 140k images). That is faster than V8.1.
It guess this resolves the issue in 8.2.

My thanks to Maik and Gilles from the digiKam team.

I’m on Windows 10 and 8 gig ram. Installed 8.2, it stops loading at random. Sometimes “Loading Tools”, sometimes “Loading images”. Anything from 150 to 500 mb usage. Made the changes suggested in this thread, including installing 8.3 and waiting for an hour. I deleted the db and pointed it to a folder with no images. It will not run. Any suggestions will ne appreciated.