[Digikam-devel] [digikam] [Bug 339720] New: Very slow tagging when missing KDE icons have been used for tags

[krienke at uni-koblenz.de]

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

            Bug ID: 339720
           Summary: Very slow tagging when missing KDE icons have been
                    used for tags
           Product: digikam
           Version: 4.3.0
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: Database
          Assignee: digikam-devel at kde.org
          Reporter: krienke at uni-koblenz.de

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

-- 
You are receiving this mail because:
You are the assignee for the bug.