Bug #1107
DigiKam hangs during search for new items
100%
Description
Directed to here from the digikam-users mailinglist.
Hi, guess I'm having the sorts of problem many Kubuntu/LinuxMint users are experiencing. Already upgraded my sqlite3/libsqlite3, also tested adding folders one by one to the collection; all was normal up to ~60 Gb of images or ~35 Mb of digikam4.db. Then the scan dies.
Similar symptoms as in http://dev.exiv2.org/issues/1098
To get rid of any doubt I even replaced the notsoveryold HDD containing the collection with a brand new HDD, but the symptoms persist.
My system is LinuxMint 17.2 64bit, but I started to see this phenomenon before upgrading from 17.1.
Backtrace:
sveinn@MIKLAFELL ~ $ gdb digikam
<snip>...
Reading symbols from digikam...Reading symbols from /usr/lib/debug/.build-id/d1/b0ef81f272f5bc1bbca37367a121860d97ac64.debug...done.
done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: /usr/bin/digikam
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffcd3bc700 (LWP 3584)]
[New Thread 0x7fffc3faf700 (LWP 3585)]
[New Thread 0x7fffc37ae700 (LWP 3586)]
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
[New Thread 0x7fffc2fad700 (LWP 3587)]
[Thread 0x7fffc2fad700 (LWP 3587) exited]
[New Thread 0x7fffc2fad700 (LWP 3588)]
[New Thread 0x7fffac3ab700 (LWP 3589)]
[Thread 0x7fffac3ab700 (LWP 3589) exited]
[New Thread 0x7fffac3ab700 (LWP 3590)]
[New Thread 0x7fffaa8f3700 (LWP 3591)]
[Thread 0x7fffac3ab700 (LWP 3590) exited]
[Thread 0x7fffaa8f3700 (LWP 3591) exited]
[New Thread 0x7fffaa8f3700 (LWP 3592)]
[New Thread 0x7fffac3ab700 (LWP 3593)]
[New Thread 0x7fffa94a2700 (LWP 3594)]
[New Thread 0x7fffa8ca1700 (LWP 3595)]
[New Thread 0x7fff9bfff700 (LWP 3596)]
[New Thread 0x7fff9b7fe700 (LWP 3597)]
[New Thread 0x7fff9affd700 (LWP 3598)]
[New Thread 0x7fff9a7fc700 (LWP 3599)]
[New Thread 0x7fff99ffb700 (LWP 3600)]
[New Thread 0x7fff997fa700 (LWP 3601)]
[New Thread 0x7fff98ff9700 (LWP 3602)]
[New Thread 0x7fff7bfff700 (LWP 3603)]
[New Thread 0x7fff7b7fe700 (LWP 3604)]
[New Thread 0x7fff7affd700 (LWP 3605)]
[New Thread 0x7fff7a7fc700 (LWP 3606)]
[New Thread 0x7fff79ffb700 (LWP 3607)]
[New Thread 0x7fff797fa700 (LWP 3608)]
[New Thread 0x7fff78ff9700 (LWP 3609)]
[New Thread 0x7fff5bfff700 (LWP 3610)]
[New Thread 0x7fff5b7fe700 (LWP 3611)]
[New Thread 0x7fff5affd700 (LWP 3612)]
[New Thread 0x7fff5a7fc700 (LWP 3613)]
[New Thread 0x7fff59ffb700 (LWP 3614)]
[New Thread 0x7fff597fa700 (LWP 3615)]
[New Thread 0x7fff58ff9700 (LWP 3616)]
[New Thread 0x7fff37fff700 (LWP 3617)]
[New Thread 0x7fff377fe700 (LWP 3618)]
[New Thread 0x7fff36ffd700 (LWP 3619)]
[New Thread 0x7fff367fc700 (LWP 3620)]
[New Thread 0x7fff35ffb700 (LWP 3621)]
[New Thread 0x7fff357fa700 (LWP 3622)]
[New Thread 0x7fff34ff9700 (LWP 3623)]
[New Thread 0x7fff1ffff700 (LWP 3624)]
[New Thread 0x7fff1f7fe700 (LWP 3625)]
[New Thread 0x7fff1effd700 (LWP 3626)]
[New Thread 0x7fff1e7fc700 (LWP 3627)]
[New Thread 0x7fff1dffb700 (LWP 3628)]
[New Thread 0x7fff1d7fa700 (LWP 3629)]
[New Thread 0x7fff1cff9700 (LWP 3630)]
[New Thread 0x7ffefbfff700 (LWP 3631)]
[New Thread 0x7ffefb7fe700 (LWP 3632)]
[New Thread 0x7ffefaffd700 (LWP 3633)]
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
[Switching to Thread 0x7fffc3faf700 (LWP 3585)]
Catchpoint 1 (exception thrown), 0x00007ffff10788b0 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007ffff10788b0 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007fffeec955a7 in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#2 0x00007fffeec95cea in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#3 0x00007fffeec964cf in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#4 0x00007fffeec96c89 in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#5 0x00007fffeec7148a in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#6 0x00007fffeec9f9c0 in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#7 0x00007fffeec40e58 in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#8 0x00007fffeec40ec0 in ?? () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#9 0x00007fffeec3c1c0 in Exiv2::XmpParser::decode(Exiv2::XmpData&, std::string const&) () from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#10 0x00007fffeebbf206 in Exiv2::JpegBase::readMetadata() ()
from /usr/lib/x86_64-linux-gnu/libexiv2.so.14
#11 0x00007ffff6368aca in KExiv2Iface::KExiv2::load(QString const&) const ()
from /usr/lib/libkexiv2.so.11
#12 0x00007ffff5c7afb6 in Digikam::DMetadata::load (
this=this@entry=0x7fffbc2d8a50, filePath=...)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/dmetadata/dmetadata.cpp:110
#13 0x00007ffff56d6c1f in Digikam::ImageScanner::loadFromDisk (
this=this@entry=0x7fffc3fae490)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/imagescanner.cpp:1550
#14 0x00007ffff56d6e00 in Digikam::ImageScanner::newFile (
this=this@entry=0x7fffc3fae490, albumId=albumId@entry=1422)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/imagescanner.cpp:289
#15 0x00007ffff566f636 in Digikam::CollectionScanner::scanNewFile (
this=this@entry=0x7fffc3faeae0, info=..., albumId=1422)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:1255
#16 0x00007ffff56727bf in Digikam::CollectionScanner::scanAlbum (
this=this@entry=0x7fffc3faeae0, location=..., album=...)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:1090
#17 0x00007ffff5672677 in Digikam::CollectionScanner::scanAlbum (
this=this@entry=0x7fffc3faeae0, location=..., album=...)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:1113
#18 0x00007ffff5673083 in Digikam::CollectionScanner::scanAlbumRoot (
this=this@entry=0x7fffc3faeae0, location=...)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:829
#19 0x00007ffff5673c5d in Digikam::CollectionScanner::completeScan (
this=this@entry=0x7fffc3faeae0)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:490
#20 0x00000000005dafaf in Digikam::ScanController::run (this=0xfd4a90)
at /build/digikam-6g9Kqs/digikam-4.12.0/core/app/database/scancontroller.cpp:756
#21 0x00007ffff161432f in QThreadPrivate::start (arg=0xfd4a90)
at thread/qthread_unix.cpp:349
#22 0x00007fffedc5f182 in start_thread (arg=0x7fffc3faf700)
at pthread_create.c:312
#23 0x00007ffff0b3947d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)
Files
History
Updated by Sveinn Felli over 6 years ago
- File svinshs.jpg svinshs.jpg added
Some more info:
exiv2 0.25 001900 (64 bit build)
Qt: 4.8.6
KDE: 4.14.2
digiKam: 4.12.0
I've been fiddling with EXIV2 commands on the directories that EXIV2 couldn't parse, such as:
exiv2 -g Olympus *.jpg
(my main camera is an Olympus), and regularly I get:
Error: XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata.
As I recall, this message sometimes came up after editing images with GIMP, right?
And actually, in the images there are duplicate entries like in XMP EXIF:
exif:UserComment[1] exif:UserComment[1]/?xml:lang x-default
What is curious is that exif-parsing of these images has been flawless during several years (at least 11), through many iterations of software & kernels, being accessed from various distributions, and never been a problem until 1-2 months ago.
Updated by Robin Mills over 6 years ago
v0.25 was released at the end of June 2015. I doubt a coincidence for your observation: never been a problem until 1-2 months ago
I'm unable to reproduce "XMP Toolkit error 203:" on Linux (Ubuntu 15.04) or MacOS-X with your test file:
673 rmills@rmillsmbp:~/clanmills $ exiv2 -vV -g svn -g version -g compiler -g platform
exiv2 0.25 001900 (64 bit build)
platform=apple
compiler=Clang
version=4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)
svn=3883
id=$Id: version.cpp 3800 2015-05-08 22:26:36Z robinwmills $
library=/usr/lib/system/libcompiler_rt.dylib
library=/usr/lib/system/libsystem_platform.dylib
674 rmills@rmillsmbp:~/clanmills $ exiv2 -px http://dev.exiv2.org/attachments/download/814/svinshs.jpg
Xmp.tiff.Software XmpText 14 digiKam-0.10.0
Xmp.tiff.ImageDescription LangAlt 1 lang="x-default"
Xmp.xmp.CreatorTool XmpText 14 digiKam-0.10.0
Xmp.dc.description LangAlt 1 lang="x-default"
Xmp.exif.UserComment LangAlt 1 lang="x-default"
675 rmills@rmillsmbp:~/clanmills $ exiv2 -pX http://dev.exiv2.org/attachments/download/814/svinshs.jpg | xmllint -pretty 1 -
<?xml version="1.0"?>
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.1.1-Exiv2">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description xmlns:tiff="http://ns.adobe.com/tiff/1.0/" xmlns:xap="http://ns.adobe.com/xap/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:exif="http://ns.adobe.com/exif/1.0/" rdf:about="" tiff:Software="digiKam-0.10.0" xap:CreatorTool="digiKam-0.10.0">
<tiff:ImageDescription>
<rdf:Alt>
<rdf:li xml:lang="x-default"/>
</rdf:Alt>
</tiff:ImageDescription>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang="x-default"/>
</rdf:Alt>
</dc:description>
<exif:UserComment>
<rdf:Alt>
<rdf:li xml:lang="x-default"/>
</rdf:Alt>
</exif:UserComment>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>
676 rmills@rmillsmbp:~/clanmills $ Updated by Robin Mills about 6 years ago
- Category set to miscellaneous
- Assignee set to Robin Mills
- Target version set to 0.26
- % Done changed from 0 to 30
- Estimated time set to 5.00 h
Updated by Robin Mills about 6 years ago
- Status changed from New to Assigned
- Start date deleted (
20 Aug 2015) - Estimated time changed from 5.00 h to 10.00 h
Updated by Robin Mills about 6 years ago
- Status changed from Assigned to Resolved
- % Done changed from 30 to 100
- Estimated time changed from 10.00 h to 3.00 h
I don't see any evidence of a bug in exiv2. I suspect there is something wrong with the linking of libexiv2 and digikam. Please try this with the next version of digikam.
The Exiv2 project cannot easily test/reproduce issues in DigiKam. We have to ask you to report issues using our command-line tools.
I don't agree that exiv2 cannot parse the following:
exiv2 -g Olympus *.jpgThe -g (--grep) command argument is intended to filter output tags. So the tag will have to contain the string 'Olympus'. For sure, it's working on your test image:
542 rmills@rmillsmbp:~/Pictures/2015/ToppingTower $ exiv2 -g Olympus http://dev.exiv2.org/attachments/download/814/svinshs.jpg Exif.Olympus.SpecialMode Long 3 Normal Exif.Olympus.Quality Short 1 High Quality (HQ) ... Exif.Olympus.NearLensStep Short 1 400 543 rmills@rmillsmbp:~/Pictures/2015/ToppingTower $And it's working fine for me on a directory of images (taken with my Nikon D5300).
544 rmills@rmillsmbp:~/Pictures/2015/ToppingTower $ exiv2 -g Model *.jpg DSC_7341.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7342.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7343.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7344.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7345.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7346.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7347.jpg Exif.Image.Model Ascii 12 NIKON D5300 DSC_7348.jpg Exif.Image.Model Ascii 12 NIKON D5300 545 rmills@rmillsmbp:~/Pictures/2015/ToppingTower $
I'm going to mark this 100%/Resolved. This issue will remain open if you wish to add new information. It will be closed during review before we ship v0.26.