Failing to load collection

Gilles Caulier caulier.gilles at gmail.com
Tue Jun 6 13:54:19 BST 2017


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/



More information about the Digikam-users mailing list