I don't agree that exiv2 cannot parse the following: exiv2 -g Olympus *.jpgThe -g (-grep) command argument is intended to filter output tags. We have to ask you to report issues using our command-line tools. The Exiv2 project cannot easily test/reproduce issues in DigiKam. Please try this with the next version of digikam. I suspect there is something wrong with the linking of libexiv2 and digikam. I don't see any evidence of a bug in exiv2. Xmp.dc.description LangAlt 1 lang="x-default" Library=/usr/lib/system/libsystem_platform.dylib Library=/usr/lib/system/libcompiler_rt.dylib
I'm unable to reproduce "XMP Toolkit error 203:" on Linux (Ubuntu 15.04) or MacOS-X with your test file: 673 $ exiv2 -vV -g svn -g version -g compiler -g platform I doubt a coincidence for your observation: never been a problem until 1-2 months ago V0.25 was released at the end of June 2015. #19 0x00007ffff5673c5d in Digikam::CollectionScanner::completeScan /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:490 #18 0x00007ffff5673083 in Digikam::CollectionScanner::scanAlbumRoot location=.)Īt /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:829 #17 0x00007ffff5672677 in Digikam::CollectionScanner::scanAlbum location=., album=.)Īt /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:1113 #16 0x00007ffff56727bf in Digikam::CollectionScanner::scanAlbum location=., album=.)Īt /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:1090 #15 0x00007ffff566f636 in Digikam::CollectionScanner::scanNewFile info=., albumId=1422)Īt /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/collectionscanner.cpp:1255 #14 0x00007ffff56d6e00 in Digikam::ImageScanner::newFile /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/imagescanner.cpp:289 #13 0x00007ffff56d6c1f in Digikam::ImageScanner::loadFromDisk /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/database/imagescanner.cpp:1550
#12 0x00007ffff5c7afb6 in Digikam::DMetadata::load filePath=.)Īt /build/digikam-6g9Kqs/digikam-4.12.0/core/libs/dmetadata/dmetadata.cpp:110 Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)Ĭatchpoint 1 (exception thrown), 0x00007ffff10788b0 in _cxa_throw ()įrom /usr/lib/x86_64-linux-gnu/libstdc++.so.6 Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Reading symbols from digikam.Reading symbols from /usr/lib/debug/.build-id/d1/.įile "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in įrom libstdcxx.v6.printers import register_libstdcxx_printers My system is LinuxMint 17.2 64bit, but I started to see this phenomenon before upgrading from ~ $ gdb digikam To get rid of any doubt I even replaced the notsoveryold HDD containing the collection with a brand new HDD, but the symptoms persist. 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. Hi, guess I'm having the sorts of problem many Kubuntu/LinuxMint users are experiencing. Directed to here from the digikam-users mailinglist.
0 kommentar(er)
