*** *** 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
I am not aware of any changes we have made here. Please create a DebugView log. Maik
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
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
Please create a DebugView log, we can read more from it than you and we have time stamps in it. Maik
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