Crash with updated xmp sidecar files found

DT 3.0.2 on Manjaro KDE.

I use Digikam for the db, but I have not open Digikam and I still get:

  1. 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.
  2. I can click on select all, but update db from selected xmps will freeze.
  3. If I only select the 2 bottom ones dated: 1969 then it doesn’t freeze.
  4. 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.

I forgot to add that I’m on DT3.0.2, Digikam 7.0 and Windows 10 2004

Could you share the xmp files associated to dt freeze ? I’ll check against the current master. Thanks

They keep it for 30 days (I’m only a guest)


If you unset “write sidecar file for each image”, do you still experience the freeze ?

On my side, dt (master) doesn’t freeze nor crashes but issues some exiv2 errors when writing back the xmp file. Trying to find on which element …

  1. The crash hasn’t happened lately, at least for the last 2 to 3 weeks.
  2. 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

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

Thank you

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.

I just checked around. Isn’t crs xmp tag from Adobe?

In 2009, I was using Lightroom v1.4x. I haven’t use Adobe for at least 4 or 5 years.

I’ve since reprocessed this image in both DT and RT.

Just deleted the crs tags and it worked.

Done :grinning:


That is exactly where I’m at as well.

Hi, I suffer the same problem, can you explain what “crs” tags are please?
Thanks, Andrew

The sidecar is a simple text file. I just use my editor to delete all the crs tags like:


Hopefully this will also help you