Bug 501834 - Scanning a Directory also reads top tree
Summary: Scanning a Directory also reads top tree
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Scan (show other bugs)
Version: 8.6.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-21 15:40 UTC by hoelzer
Modified: 2025-04-11 18:14 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hoelzer 2025-03-21 15:40:47 UTC
SUMMARY

When scanning a directory on the left sidebar via right-click and selecting refresh the process takes a very long time, e.g. a folder containing 100 images takes about 10 - 15 minutes to refresh.
This is only the case when the folder that is to be refreshed is inside a directory with many other folders. It seems that the more folders are on the same directory level, the longer it takes to refresh the directory. This leeds me to the assumption that the whole tree is scanned when only the directory itself needs to be refreshed.

STEPS TO REPRODUCE
1. On the left side bar select a folder, right-click and select "refresh"

OBSERVED RESULT

When this folder is inside a directory with many folders (>100) on the same level, the scan takes 10-15 minutes, wile the folder itself only contains few images (< 100).

EXPECTED RESULT

Scanning the folder should only take a few seconds as it contains only few images (< 100).

SOFTWARE/OS VERSIONS
Windows: 11
Comment 1 caulier.gilles 2025-03-21 15:54:22 UTC
Scanning on the left sidebar ? Scan for what  ? Quality, auto-tags, Similarity, Faces ???

Gilles Caulier
Comment 2 Maik Qualmann 2025-03-21 19:52:22 UTC
Only the current album folder is executed during a refresh (reading the metadata to the database). I tested it again here specifically.

Does your album possibly contain symmolic links that digiKam could follow?

Maik
Comment 3 hoelzer 2025-03-22 06:44:53 UTC
(In reply to caulier.gilles from comment #1)
> Scanning on the left sidebar ? Scan for what  ? Quality, auto-tags,
> Similarity, Faces ???
> 
> Gilles Caulier

I'm using the "Refresh" function of the context menu to get new and changed image thumbnails in the album.

Christian Hölzer
Comment 4 hoelzer 2025-03-22 07:12:51 UTC
(In reply to Maik Qualmann from comment #2)
> Only the current album folder is executed during a refresh (reading the
> metadata to the database). I tested it again here specifically.
> 
> Does your album possibly contain symmolic links that digiKam could follow?
> 
> Maik

No, there are no symbolic links. The album is accessed over a network share (served via samba on debian 12), digikam is running on Windows 11.
I did the following test, using one top folder with 578 subfolders (all album folders have been read into the database before):

1. Remove all subfolders except one empty one
2. Populate the remaining subfolder with 100 images
3. Execute "Refresh" on the subfolder

Result:

The refresh took about 10 Minutes, and digikam now displays only the one remaining subfolder, having removed all the other ones. 
So digikam is operating on the other album folders, at least reading the directory/file structure.
Comment 5 Maik Qualmann 2025-03-22 07:42:11 UTC
Please create a DebugView log, then we can see exactly which files are being processed, as described here for Windows:

https://www.digikam.org/contribute/#windows-host

Maik
Comment 6 Maik Qualmann 2025-03-23 16:48:18 UTC
Album Refresh consists of two modules: the New Item Scanner and the Thumbnail Creator.
The New Item Scanner scans the album recursively, including subdirectories. The Thumbnail Creator only reads the current album.

Well, I wouldn't change anything here at the moment so that newly added albums are also recognized. Is reading subalbums for changes so slow on your network drive?

Maik
Comment 7 caulier.gilles 2025-04-11 18:14:01 UTC
Hi,

The 8.7.0 pre-release Windows installer from today have been rebuilt from
scratch with Qt 6.8.3, KDE 6.12, OpenCV 4.11 + CUDA support, Exiv2 0.28.5, ExifTool 13.27, ffmpeg 7, all image codecs updated to last version (jxl, avif, heif, aom, etc.).

Please try with this version to see if your problem still reproducible...

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

Thanks in advance
Best regards

Gilles Caulier