| Summary: | Updating tags is slow when thumbnails are visible | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Peter Potrowl <peter017> |
| Component: | Database-Thumbs | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 0.9.3 | ||
| Target Milestone: | --- | ||
| Platform: | Mandriva RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.9.5 | |
| Sentry Crash Report: | |||
|
Description
Peter Potrowl
2008-07-20 05:29:08 UTC
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 |