Notice the darktable date on the right for the bottom 2 images: 1969. These never get updated each time I open DT. (I have not used Digikam in at least 3 days.
I can click on select all, but update db from selected xmps will freeze.
If I only select the 2 bottom ones dated: 1969 then it doesn’t freeze.
If there’s another file like the first or second one, then DT will just freeze.
Any way of debugging this problem and find out what I did (so I don’t do it again)?
Similar issue here. I’m figuring out a workflow on how to use Digikam as my DAM and Darktable as the raw processor. I sometimes manage to update my darktable database from the digikam xmp, but 1 time in 2 it just crashes DT
I’m on windows 10
In your case, could it be because Linux uses unix time stamps which is 1 januari 1970 and the timestamp of your images predate that? (just a wild guess)
I think I also have seen lockups with digiKam edited-XMPs and then darktable trying to reload the XMP content. But currently with my setup (digiKam 7.0.0 and darktable master darktable_3.1.0~git2511.4226ac17c_amd64 (running in MX Linux - Debian 10based) I do no longer see the lockups. Might be taht there have been done chenges in DT/digiKam to enhance XMP interoperability.
The crash hasn’t happened lately, at least for the last 2 to 3 weeks.
Every time I open DT, I get the same screen with the same files > I select all > overwrite selected xmp files > DT clears that window > close. Next time, it happens again.
$ darktable --version
this is darktable 3.0.2
copyright (c) 2009-2020 johannes hanika
darktable-dev@lists.darktable.org
compile options:
bit depth is 64 bit
normal build
SSE2 optimized codepath enabled
OpenMP support enabled
OpenCL support enabled
Lua support enabled, API version 5.0.2
Colord support enabled
gPhoto2 support enabled
GraphicsMagick support enabled
OpenEXR support enabled
Yes … that’s the behavior I have on my side. A part of the explanation is that dt doesn’t succeed in saving the xmp file, due to some exiv2 error in your xmp data.
Having the config “look up for updated xmp at start up” set, dt detects a difference on file timestamp … but when you ask to update the database dt fails to save the xmp. So the timestamp remains unchanged… and the detection is triggered endlessly.
That’s where I am.
removing crs data, which seem to be related to an other image editor, everything is fine.
Exiv2 doesn’t like those data.
I’m afraid we cannot do anything for that. Maybe you could check on exiv2 side.