Bug 499428

Summary:	Moving of an image from one album to another (on remote storage) can take 20-30 seconds, where prior versions were effectively instant
Product:	[Applications] digikam	Reporter:	Roland <carbonwerkes>
Component:	Albums-Engine	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	metzpinguin
Priority:	NOR
Version First Reported In:	8.6.0
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Roland 2025-02-02 21:38:12 UTC

***
***

SUMMARY
If I select an album, where the thumbnails are shown in the main view, a drag (copy or move) of any of those thumbnails to another folder/album can take 20-30 seconds. This is seen on an instance where content is on a NAS. This was not a problem as of a couple of builds ago. In evaluating what is going on, there are a huge number of reads/writes going on for a move of a 500kb file. We are talking 2-3mb/s for 20s. It seems likely this is an SQL thing, since I can add files to an album from my desktop with effectively zero delay, and likewise, move content from digiKam to my desktop as quickly. If the issue were file transfer or simple db updates for adds/deletes, the lag would be seen with these ops. It is only seen with moves within digiKam.

STEPS TO REPRODUCE
1.  drag a file from an album to another album. 
2. 
3. 

OBSERVED RESULT
Significant lag in a move or copy operation. This is a disk i/o thing. Put a counter/monitor on IO and watch the number of transactions involved in an internal move/copy vs an external to internal move, or internal to external.  

EXPECTED RESULT
Fast move/copy ops, where I dont see 10s of mb of disk i/o for a single file move of a 500kb file. 

SOFTWARE/OS VERSIONS
Windows: 10
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Comment 1 Maik Qualmann 2025-02-02 21:43:31 UTC

I am not aware of any changes we have made here. Please create a DebugView log.

Maik

Comment 2 Roland 2025-02-03 10:00:56 UTC

Hi Maik. I grabbed a debug, but there is nothing of note. I did notice that this issue is affecting albums with high file counts. Example, the problematic folder has about 10,000 files in its root, and some subfolders. Those are on a NAS share. And you might think- OK, well, slow link or NAS. But I can drag a file from the desktop into digikam (to the problematic folder)- and that move happens almost instantly- no 10-20 second halt while thousands of reads/writes are generated. But copy a file from a folder with a small file count to that problematic folder- its 10-20 seconds.

So, I dont really know what is different between these 2 cases. if digiKam is using the filesystem copy/move calls, there should not be a difference in the process except for the database updates. I moved the database to a local SSD, and the problem persists. So perhaps there are additional processes going on along with an internal move- maybe some folder scan, or perhaps it uses a different copy/move mechanism that is more sensitive to high file counts in a source or destination folder?

This was not happening as of a couple of weeks ago best I can recall. The problem folder is an aggregation point for unclassified files that need to be tagged etc- so this has been a source with more files previously than now- since none new have been added, only moved out.

If there are any tests I can run on this end- I will do so as time permits. Just let me know-

Best
R

Comment 3 Maik Qualmann 2025-02-03 11:25:15 UTC

It doesn't really matter if an album contains a lot of files, because a file copy or move action takes place directly in the database and does not trigger a scan. But it could be that you have activated the option to monitor albums for external changes in the collection settings?

Maik

Comment 4 Maik Qualmann 2025-02-03 11:31:10 UTC

Please create a DebugView log, we can read more from it than you and we have time stamps in it.

Maik

Comment 5 caulier.gilles 2025-04-11 18:13:37 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