Version: 0.9.3 (using KDE 3.5.9) Installed from: Mandriva RPMs I select some pictures in the middle window to add a tag to them. When the thumbnails are visible (ie : currently displayed on the screen), the updating is slow (a few seconds). But when I scroll to hide them before selecting the tag (I don't see those thumbnails anymore on the screen), the updating is fast (less than one second)... When there are visible and non-visible thumbnails at the same time, the progression bar (bottom of the screen) goes much faster when updating the non-visible ones than when updating the visible ones. I find it strange, is should be the same speed to tag all the thumbnails, and then update the display for the visible thumbnails.
Sound like a problem relevant with sqlite3 (database). I recommend to try last stable 0.9.4 where this problem have been fixed. Gilles Caulier
Gilles, this might be a problem of updating the icon view all the time a tag has been assigned. I still can confirm this with the newest sqlite3. If a tag is assigned, it will be displayed in the image description below the thumbnail (if enabled). If you disable the "show digiKam tags" option in the album view settings, it seems to be fast all the time. Andi
Andi, Look like 3.6.0 sqlite release is out. Can you update sqlite3 amalgamation code from here: http://www.sqlite.org/sqlite-amalgamation-3_6_0.zip ... to /libs/sqlite3 and look if problem still exist ? Gilles
Hi Gilles, I installed sqlite3-3.6.0 and it is horribly slow! I tagged 400 images (should not have done this :-)) and it took me about 10 mintes to finish!!! What's wrong with sqlite in the last time? Those optimizations are really killing performance here... Andi
Andi, I have no idea. Try to contact Amarok team from IRC channel, and ask if the probem can be reproduce outside digiKam. Note : i remember here that Mandriva 2008.1 use libsqlite 3.5.6 by default. With this version, i have never seen any problems like this. Perhaps we need to backport this version inside digiKam core by default. Gilles Caulier
Hi Gilles, this is getting weirder right now. I installed the version you mentioned (3.5.6), still very slow. So I ran "make clean" in the libs/sqlite3 folder to really have a fresh lib. Still assigning tags is VERY slow (~ 3 min for 400 images). I installed 3.5.9 again, speed is better but not satisfying. sqlite3 3..6.0 is slower again. But all those slowdowns can only be seen when ASSIGNING tags (and especially in subfolder recursive mode), not REMOVING tags. One reason for this might be the full debugging output to console, every image is printed to console like this: =============================================== /mnt/data/fotos/2003/sonstiges/2003_sonstiges_070.jpg ==> Keywords: (null) digikam: /mnt/data/fotos/2003/sonstiges/2003_sonstiges_070.jpg ==> Author: Andi Clemens digikam: /mnt/data/fotos/2003/sonstiges/2003_sonstiges_070.jpg ==> Author Title: digikam: /mnt/data/fotos/2003/sonstiges/2003_sonstiges_070.jpg ==> Credit: digikam: /mnt/data/fotos/2003/sonstiges/2003_sonstiges_070.jpg ==> Source: digikam: /mnt/data/fotos/2003/sonstiges/2003_sonstiges_070.jpg ==> Copyright: digikam: /mnt/data/fotos/2003/sonstiges/2003_sonstiges_071.jpg ==> Comment: =============================================== This might slowdown the system, but why only on ASSIGNING? Maybe this is not sqlite3's fault, but digiKam's...? We need to go deeper in code analysis here I guess. Andi
Andi, You have right. These lines are only for debug. Look in metadatahub, or dmetadata, or at least, libkexiv2... I don't remeber where exactly... Note : these debug lines are removed automatically when you compile a final package (KDebug). Gilles
Gilles, but I don't think that is the slowdown in general, because those information are also shown when REMOVING a tag... but like I said before: ASSIGNING is slow, REMOVING is acceptable. Andi
Gerhard, somehow your post was not pasted in here... I'll quote it: On Monday 21 July 2008 06:20:47 Gerhard Kulzer wrote: > Tagging is excruciatingly slow here, about 1 tag per second (I'm writing > the information into the files IPTC data). When i tag more than 26 images, > it takes hours to complete and I get this error message in the konsole: > QPainter::begin: A paint device can only be painted by one painter at a > time. and after 26 tags: > digikam(25441): Failure executing query: > digikam(25441): "UPDATE Images SET category=?, modificationDate=?, > fileSize=?, uniqueHash=? WHERE id=?;" digikam(25441): "database is locked > Unable to fetch row" > digikam(25441): Bound values: (QVariant(int, 1) , QVariant(QDateTime, > QDateTime("Mon Jul 21 06:13:50 2008") ) , QVariant(int, 184002), > QVariant(QString, "8cd79cd0720ecf511517c0702fcf8ef6") , > QVariant(qlonglong, 67634) ) di > Does that give you any indication? > Gerhard Never seen this before, what version of digiKam are you using? Andi
The SQL in Gerhard's message is from 0.10.0, so that's a different problem.
Gerhard, your post is missing again... Marcel only wants to say that your report is somehow invalid for this bugreport here, because this one is for digiKam 0.9.3 that uses totally different SQL statements and infrastructure then the 0.10.x series.
The problem that Gerhard has reported has been fixed in trunk by a number of recent commits. For the bug reported above, this is off topic.
Following comment #12 from Marcel, this file can be closed now. Gilles Caulier