When any tag have defined non existent now in system, user icon all operations with tags work very slow. Problem exists also when in main window tag sidebar is displayed. After reset all icons problem disappear. Reproducible: Always Steps to Reproduce: 1. add any icon for any tag 2. remove icon form system (or change name direct in database) 3. run digikam, open photo tag side bar
Which version of digiKam you use ? Which version of KDE you use ? Go to Help/Components Info for details. Gilles Caulier
> Which version of digiKam you use ? > > Which version of KDE you use ? > > Go to Help/Components Info for details. Digikam 2.9.0 KDE 4.8.5 Now, but in earlier versions i had same problem.
Hi, I have / had the same issue. After installing Digikam 2.7 digikam became extreamly slow when working with tags. Digikam 2.8 and 2.9 did not resolve the issue. Today I found an email about poor performance when tags have icons which do not exist (http://digikam.1695700.n4.nabble.com/digiKam-is-slow-td4659589.html). I logged into my digikamdb (mysql) and set all tag "iconkde" entries to NULL. Immediatelly perfromance was back to normal! Searching tags now responds instantly, before it was several seconds. I then restored the old iconkde settings and performance was poor again. After fixing just the missing icons digikam is usable again. Best Regards Bernhard Kappler
Trying to reproduce. I have 800 tags with the "tag-places" kde icon. Changing that in the database to tag-placesxy. Starting digikam. Tag-places are gone, now with default icon. Now change when listing the images of a tag. Apparently, no problem adding a new tag. Which are the operations turning very slow with a missing icon?
Well... Now I can't reproduce problem too... Maybe it's specific openSUSE or KDE problem resolved with updates.
ok, upgraded to Ubuntu 10/12 in the meantime. KDE 4.9.3 / Digikam 2.9 Can no longer reproduce the issue! Seems to be solved within KDE icon handling. Best Regards Bernhard
Hi, I had the same slowness problem since quite a while but thought I had to many tags assigned. The problem is only visible when tag sidetab is visible. Then even selecting one photo takes about 2sec until the tags assigned are shown in the sidetab and during this time digikam does not react on any mouse input. Other actions took even much longer. I did an strace at this time on the digikam process and found many many lines where digikam searches eg kgeography.png which is not where it is searched (/usr/share/icons) but instead lives in /usr/share/doc/kde/HTML/de/kgeography/kgeography.png where KDE does not search: 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 many more other icons that are not found as well which cause the same search delay. After I read about this bug I opened my sqlite3 digikam4.db database and did a: sqlite> update Tags set iconkde='' where iconkde not null; After this modification all the tag icons have of course gone but digikam is much, much faster. So missing kde icons seem to have caused this slowness. Probably a (possibly) long while ago these icons were in another place and kde could find them and some upgrades moved them away. I run digikam 4.3.0 on openSuSE 13.1 with KDE 4.11 So what would be needed to get out of this problem is a database cleanup procedure for tag icons that no longer exist.
Hi krienke, Please open a file in digiKam/database bugzilla section about this problem. A database Maintenance tool is planed and this rule about system icon assigned to Tags must be analyzed to fix this problem. Thanks in advance Gilles Caulier