Bug 460153 - Deleting an album takes many seconds
Summary: Deleting an album takes many seconds
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-Trash (other bugs)
Version First Reported In: 7.8.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-09 10:18 UTC by Peter
Modified: 2022-10-10 17:22 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 7.9.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2022-10-09 10:18:38 UTC
I use mySql database and remote network disks.
If you deleting an album in the tree of albums, the operation apparently takes many seconds. digiKam will do deleting album in the background (album immediately disappear in the file manager), but in the window of digiKam  stays there long seconds the deleted album.
This is extremely disturbing behavior.

STEPS TO REPRODUCE
1. Select an album in the tree of Albums
2. Delete album

OBSERVED RESULT
digiKam will do deleting album in the background (album immediately disappear in the file manager), but in the window of digiKam  stays there long seconds the deleted album.

EXPECTED RESULT
After deletion, the album immediately disappears from the tree of albums.

SOFTWARE/OS VERSIONS
Windows: 10
macOS: -
Linux/KDE Plasma: Linux Mint 20.x
(available in About System)
KDE Plasma Version: -
KDE Frameworks Version: -
Qt Version:
Comment 1 caulier.gilles 2022-10-09 10:27:39 UTC
Hi,

Right i checked here with my NAS and a wifi connection, and the delay is due to the network data exchange with the remote database.

In fact the GUI update the deleted album status after the deletion is complete.

Proposals : 
1/ remove the album from the GUI, complete the operation with the database in background. If operation fail, restore the album in GUI depending of the error returned with a pop-up dialog.
2/ alternative is to block GUI while deleting the album and displaying a progress bar for long operation where an error message can be show if necessary.

The 2/ is the most used way, but the disadvantage is the GUI time latency with a blocking interface.
There is not a best solution...

Best

Gilles Caulier
Comment 2 Maik Qualmann 2022-10-09 10:35:15 UTC
When deleting albums, even if there are sub albums, some database operations must be performed. All items in the albums that have been deleted must be marked as deleted, possible groupings must be ungrouped. All this takes time if the database is not very fast.

Maik
Comment 3 Maik Qualmann 2022-10-09 10:39:34 UTC
Most of the time is probably consumed by the scan on the network collection that we start after deleting/moving albums, since it also runs through the collection recursively. We can optimize this.

Maik
Comment 4 Maik Qualmann 2022-10-09 14:26:12 UTC
Git commit bc10edb481306279e1ca6ff56731224ef328b130 by Maik Qualmann.
Committed on 09/10/2022 at 14:25.
Pushed by mqualmann into branch 'master'.

perform database operation directly after delete album or items

M  +120  -91   core/libs/database/utils/ifaces/dio.cpp

https://invent.kde.org/graphics/digikam/commit/bc10edb481306279e1ca6ff56731224ef328b130
Comment 5 Maik Qualmann 2022-10-09 14:28:10 UTC
Gilles, can you test whether it brings the desired speed advantage when deleting/trashing? I plan to do this for all other file operations as well, to avoid unnecessary directory scanning.

Maik
Comment 6 caulier.gilles 2022-10-09 14:40:10 UTC
Hi Maik,

As i can see the process sounds like faster, but as i use WIFI i can judge is it's really better ++ or not. Also i use only Linux, not Windows here with the NAS.

The patch is not too much intrusive. It only touch one source file. We can try to back-port temporally to qt5-maintenance, i rebuild the Window installer, and Peter can check if performances are better. If not, patch can be easily reverted.

Peter, what do you think about ?

Gilles
Comment 7 Peter 2022-10-09 16:16:04 UTC
Hi Gilles and Maik.

Thank you both for your work.
I will check this.
Regards
Peter
Comment 8 Maik Qualmann 2022-10-09 19:48:15 UTC
Git commit c348a807bab567502b657f0cf4d40cec9b00fe90 by Maik Qualmann.
Committed on 09/10/2022 at 19:47.
Pushed by mqualmann into branch 'qt5-maintenance'.

apply post processing file operations from git/master

M  +196  -122  core/libs/database/utils/ifaces/dio.cpp

https://invent.kde.org/graphics/digikam/commit/c348a807bab567502b657f0cf4d40cec9b00fe90
Comment 9 Peter 2022-10-10 05:51:29 UTC
Tested patch in the digiKam-7.9.0-20221010T041758-Win64.exe
Excellent work! Deleting is very very fast!

Original fault: I can't reproduce anymore.

Thank You Maik and Gilles!
Comment 10 caulier.gilles 2022-10-10 08:25:36 UTC
Peter,

All last optimizations from Maik are now integrated in current 7.9.0 pre-release installer for Windows available here :

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

Please, test and give us a feedback in this room.

Thanks in advance

Gilles Caulier
Comment 11 Maik Qualmann 2022-10-10 08:42:16 UTC
Gilles, Peter was very quick this morning, see Comment 9. ((:-))

Maik
Comment 12 caulier.gilles 2022-10-10 08:47:32 UTC
(:=)))...

I don't take a look to comment #9. Great...

Gilles
Comment 13 Maik Qualmann 2022-10-10 17:22:02 UTC
Git commit 872e809a94420f63a8655e9bc77ead3e7af20746 by Maik Qualmann.
Committed on 10/10/2022 at 17:21.
Pushed by mqualmann into branch 'qt5-maintenance'.

sync with master
FIXED-IN: 7.9.0

M  +2    -1    NEWS
M  +17   -35   core/libs/database/utils/ifaces/dio.cpp
M  +3    -1    core/libs/iojobs/iojob.cpp
M  +17   -2    core/libs/iojobs/iojobdata.cpp
M  +1    -0    core/libs/iojobs/iojobdata.h

https://invent.kde.org/graphics/digikam/commit/872e809a94420f63a8655e9bc77ead3e7af20746