Unnecessary xmp write on read
I have a huge collection of files on my NFS server and use that from 2 different computers. Whenever I start one darktable instance all xmp files are scanned for change (I have explicitly turned on this feature in the settings to be able to work from 2 computers on the same database). The problem is that for each xmp file the xmp timestamp is updated and such darktable hangs a while, then presents me a UI "updated xmp sidecar files found", I check them all (since I dont know which file has been changed), and then darktable hangs for several minutes.
Right now I was able to file this bugreport while dt was reading in the updated xmp sidecar files.
Don't write XMP when they didn't change
When the XMP already exists on disk then we hash it first, compare that
hash to the final data we are about to write and skip writing if the
hashes match. Unfortunately the hashes can't be cached in db as one
major use case is using the same images with several dbs or changing the
XMPs from the outside.
#2 Updated by Tobias Ellinghaus over 2 years ago
- % Done changed from 50 to 100
- Status changed from In Progress to Fixed
Applied in changeset darktable|235209e682e374eb76a83fb7d8692fac5804aa0b.