Bug 339720 - Very slow tagging when missing Plasma icons have been used for tags
Summary: Very slow tagging when missing Plasma icons have been used for tags
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Albums (show other bugs)
Version: 4.3.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-06 06:38 UTC by krienke
Modified: 2019-12-25 15:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description krienke 2014-10-06 06:38:32 UTC
Hi,
since quite a while I had the problem that when digikams tag sidetab is visible (showing your tag hierarchy) everything in digikam is terribly slow. Just selecting a photo it takes about 2sec until all the 5  tags of that photo have been displayed as "selected" in the sidetab. Simply scrolling in the tag list is slow, displaying photos in the image editor (while tag window is visible) is a real pain since it takes very very long to to go to the next/previous photo (up to 6sec). When the tag sidetab is not selected but another one of the sidetabs then work is much faster.

Searching for this kind of problem I found bug: 

https://bugs.kde.org/show_bug.cgi?id=307219

To find out more I straced digikams main process when working with tags. I found that digikam is searching without success for different tag icons like the following strace output demonstrates:

pid 30088] access("/usr/share/icons/hicolor/32x32/status/kgeography.png", R_OK) = -1 ENOENT (No such file or directory) [pid 30088] access("/usr/share/icons/hicolor/36x36/actions/kgeography.png", R_OK) = -1 ENOENT (No such file or directory) [pid 30088] access("/usr/share/icons/hicolor/36x36/animations/kgeography.png", R_OK) = -1 ENOENT (No such file or directory) [pid 30088] access("/usr/share/icons/hicolor/36x36/apps/kgeography.png", R_OK) = -1 ENOENT (No such file or directory)
....

There are hundreds of such errors for many different icons.

To get around this problem I manually removed all tag icons by running the following sqlite statement on digikams database:

sqlite> update Tags set iconkde='' where iconkde not null; 

After this modification all the tag icons have of course gone but digikam was much, much faster. So missing kde icons seem to have caused this slowness. A possibly long while ago these icons were in another place and kde could find them and some upgrades moved them away or deleted them completely.

So what is actually needed is a regular check and repair if any of the tag icons is no longer available to avoid such delays.   

I run digikam 4.3.0 on openSuSE 13.1 with KDE 4.11.


Reproducible: Always
Comment 1 caulier.gilles 2014-10-07 10:57:12 UTC

*** This bug has been marked as a duplicate of bug 315574 ***
Comment 2 caulier.gilles 2019-12-25 15:46:01 UTC
Not reproducible using digiKam 7.0.0 beta1.