Failing to load collection

Tue Jun 6 14:43:48 BST 2017

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170606/066a1b93/attachment.html>