Failing to load collection

Tue Jun 6 14:51:00 BST 2017

Well it simple. digiKam is stopped in debugger due to a C++ exception.
You get the GDB prompt and it wait a command to hack.

Just enter "bt" for backtrace to catch the full backtrace, and
especially where the program is stopped in source code.

The notice is explained in details here :

https://www.digikam.org/contribute/

Note : I'm 90% sure that you have a problem with Exiv2 with a DNG
file... (:=)))...

Gilles Caulier

2017-06-06 15:43 GMT+02:00 Sigfrid Lundberg <sigfrid at sigfrid-lundberg.se>:
> Thanks for rapid response...  Starting with digikam-5.6.0-01-x86-64.appimage
> I did with debug option
>
> 1. I created an empty directory (~sigge/digikam) for the db
> 2 Tried with the very first directory inside my gallery area, which contains
> a some 120 JPGs.
>
> I then got to 85% of that directory, with the following output from GDB and
> digikam:
>
> digikam.dimg: "/home/sigge/Dropbox/galleri/2011-2012-freddy/P1080855.JPG"  :
> JPEG file identified
> digikam.database: Adding new item
> "/home/sigge/Dropbox/galleri/2011-2012-freddy/P1080855.JPG"
> digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal =>
> QDateTime(2012-01-08 16:43:57.000 CET Qt::TimeSpec(LocalTime))
> digikam.metaengine: DateTime (Exif digitalized):  s�n jan. 8 16:43:57 2012
> digikam.metaengine: Orientation => Exif.Image.Orientation =>  8
> digikam.database: Scanning took 10 ms
> digikam.database: Finishing took 0 ms
> digikam.metaengine: Exiv2 ( 2 ) :  Directory OlympusCs, entry 0x0101: Strip
> 0 is outside of the data area; ignored.
>
> digikam.dimg: "/home/sigge/Dropbox/galleri/2011-2012-freddy/P1080856.JPG"  :
> JPEG file identified
> digikam.database: Adding new item
> "/home/sigge/Dropbox/galleri/2011-2012-freddy/P1080856.JPG"
> digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal =>
> QDateTime(2012-01-08 16:44:02.000 CET Qt::TimeSpec(LocalTime))
> digikam.metaengine: DateTime (Exif digitalized):  s�n jan. 8 16:44:02 2012
> digikam.metaengine: Orientation => Exif.Image.Orientation =>  8
> digikam.database: Scanning took 12 ms
> digikam.database: Finishing took 0 ms
> [Switching to Thread 0x7fffe1308700 (LWP 16323)]
>
> Thread 5 "Digikam::ScanCo" hit Catchpoint 1 (exception thrown),
> 0x00007fffee1848bd in __cxa_throw ()
>    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb)
>
>
> I still have it running, so if you have suggestions for next step, I can
> continue!
>
> Sigge
>
>
>
>
> On 6 June 2017 at 14:54, Gilles Caulier <caulier.gilles at gmail.com> wrote:
>>
>> Hi,
>>
>> I'm not sure if the DNG file identified is really the problem.
>>
>> But it's clear that something is wrong with a file scanned to populate
>> the database.
>>
>> I suspect a problem with Exiv2, which is mostly used to scan image
>> properties in background.
>>
>> So the best way to identify the problem, especially the image file, is :
>>
>> 1/ use only the last 5.6.0 pre-release AppImage from GDrive repository.
>> 2/ start a clean instance of digiKam from scratch.
>> 3/ Import step by step albums. Not all in one step.
>> 4/ When the album containing the image freeze digiKam, share the datat
>> somewhere on the web to test here in local.
>>
>> Note : if there is a crash in the thread due to Exiv2, the crash will
>> not close the application, but we can catch it to identify the
>> problem. Run the AppImage from the console with the "debug" argument.
>> This will run digiKam in GDB. Run AppImage with "help" argument for
>> details.
>>
>> Best
>>
>> Gilles Caulier
>>
>>
>>
>> 2017-06-06 14:44 GMT+02:00 Sigfrid Lundberg <sigfrid at sigfrid-lundberg.se>:
>> >
>> > Dear everybody,
>> >
>> > I'd like first say, warmly, thanks for an excellent product. I've been a
>> > daily user since about 10 years.
>> >
>> > I've a collection of close to 10000 raw images  *.DNG, *.ORF and *.RW2
>> > formats. DNG is about 75% of these. I've kept about 10% of the photos
>> > I've
>> > made. digikam has been essential in weeding and curating the collection
>> > (from about 100000 to 10000), and writing captions, applying
>> > tags/keywords
>> > and geo-tagging the all items.
>> >
>> > I've always ensured that data is written back to the exif header and
>> > that
>> > there are xmp files in the file system.  The collection is stored in a
>> > file
>> > system which is also a part of my Dropbox area.
>> > I've share the same collection over more than one computer, but then had
>> > the
>> > sqlite database files in directories outside Dropbox. Worked without
>> > problem.
>> >
>> > A few nights ago, my computer wanted to go from Ubuntu 14.04 LTS to
>> > 16.04
>> > LTS, and I decided to allow that. When doing that, I felt that it would
>> > be
>> > time to go to digikam 5.5.0. It just didn't work.
>> >
>> > I've
>> >
>> > 1. Installed the appimage (5.5.0 and 5.6.0)
>> > 2. Installed the digikam5 version for ubuntu according to tutorials on
>> > the
>> > Net.
>> > 3. I've compiled it from sources (been through all the cmake and
>> > dependency
>> > manage stuff), and got executable binaries.
>> >
>> > finally I
>> >
>> > 4. Downgraded to digikam 4 again.
>> >
>> > Sorry, but it doesn't work. There is no difference in having the
>> > database
>> > files inside our outside the collections. Not even downgrading helped.
>> >
>> > What happens in all four cases is that digikam reads about 25% of the
>> > collection, and then it sighs deeply, printing to STDOUT what I've added
>> > below (seen people mentioning similar problems on mailing lists, but
>> > I've
>> > not found a clear answer).
>> >
>> > The raw image in question is perfectly readable:
>> >
>> > https://www.dropbox.com/s/zwh1seo5gced12b/R0011071.DNG?dl=0
>> >
>> > Apart from dropbox (which actually make the raw processing without
>> > problems), I have successfully read this image using gimp and
>> > rawtherapee,
>> > so the file shouldn't be corrupt. After failing on that one, the process
>> > won't  recover. The corresponding xmp file is well formed according to
>> > xmllint.
>> >
>> > Closing digikam, and doing  dump and refresh of the  database using
>> > sqlite3
>> > command line tool doesn't help.
>> > It still tries to reread the collection and ends at the same item. If I
>> > move
>> > this image outside the collection, remove the database files and start
>> > over
>> > it ends the same way for some other item.
>> >
>> > Right now I'm desperate since my work-flow is gone.
>> >
>> > Any clue, anyone?
>> >
>> > Thanks in advance
>> >
>> > Sigfrid
>> >
>> >
>> >
>> >
>> > digikam.metaengine: DateTime (Exif digitalized):  tors dec. 22 20:37:23
>> > 2011
>> > digikam.metaengine: Orientation => Exif.Image.Orientation =>  1
>> > digikam.database: Scanning took 2 ms
>> > digikam.database: Finishing took 0 ms
>> > digikam.dimg: "/home/sigge/Dropbox/galleri/201112-201112/R0011071.DNG"
>> > :
>> > RAW file identified
>> > digikam.geoiface: ----
>> > digikam.geoiface: ----
>> > digikam.general: Using  4  CPU core to run threads
>> > digikam.general: Stacked View Mode :  0
>> > digikam.general: Action Thread run  1  new jobs
>> > digikam.dbengine: Database is locked. Waited 0
>> > digikam.geoiface: ----
>> > digikam.dbengine: Database is locked. Waited 250
>> > digikam.dbengine: Database is locked. Waited 500
>> > digikam.dbengine: Database is locked. Waited 750
>> >
>> > ....
>> >
>> > digikam.dbengine: Database is locked. Waited 9500
>> > digikam.dbengine: Database is locked. Waited 9750
>> > digikam.dbengine: Database is locked. Waited 10000
>> > digikam.dbengine: Detected locked database file. There is an active
>> > transaction. Waited but giving up now.
>> > digikam.dbengine: Failure executing query:
>> >  "SELECT id FROM Albums WHERE albumRoot=? AND relativePath=?;"
>> > Error messages: "Unable to fetch row" "database table is locked: Albums"
>> > 6 1
>> > Bound values:  (QVariant(int, 1), QVariant(QString, "/200708-200712"))
>> > digikam.general: Data From DBJobsThread is null:  true
>> > digikam.general: Cancel Main Thread
>> > digikam.general: One job is done
>> > ^C
>> >
>> >
>> >
>> >
>> > --
>> > Sigfrid Lundberg, Ph.D., System developer
>> > Lund, Sweden
>> > http://sigfrid-lundberg.se/
>
>
>
>
> --
> Sigfrid Lundberg, Ph.D., System developer
> Lund, Sweden
> http://sigfrid-lundberg.se/