https://bugs.kde.org/show_bug.cgi?id=499428
Bug ID: 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
Classification: Applications
Product: digikam
Version: 8.6.0
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Albums-Engine
Assignee: digikam-bugs-n...@kde.org
Reporter: carbonwer...@hotmail.com
Target Milestone: ---
***
***
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
--
You are receiving this mail because:
You are watching all bug changes.
