Digikam is configured to write to sidecars only. Select multiple images, e.g. about 100. Apply the same tag to all of them, using the Captions pane. For most images the sidecars are updated correctly, but for a few of them the sidecars are truncated to just their first line. This affects a different subset of files each time a tag is applied, apparently at random. The console output shows most sidecars being written without error messages, while for the few files concerned it shows: digikam.metaengine: Exiv2 ( 3 ) : XMP Toolkit error 101: Unregistered schema namespace URI digikam.metaengine: Exiv2 ( 3 ) : Failed to encode XMP metadata. This behaviour happens on OS X. Running under linux (ubuntu) in a virtual machine I do NOT see the same problem.
This problem also occurs when writing metadata to the image files. To test this, I changed the digikam preferences to not use sidecars. The test images are jpegs and I am writing just one tag to them, "print". The console shows a few error messages the same as in the initial report, and for a few files the metadata is NOT written. Again, this is running on OS X, updated to Sierra (the initial report was under El Capitan).
I build a new version of OSX installer for next release 5.4.0, using Exiv2 shared lib 0.26-svn not yet released, but including more than 200 bugfixes. It will be interesting to see if this file still reproducible. The OSX installer is available here : https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier
Thank you for doing that Gilles. I have tested the new version and the behaviour is the same: occasional errors in writing metadata to image files or sidecars, when updating many images at once. (I updated the bug title and component to be more precise.) Another way to trigger the problem is "Album->Write Metadata to Images", which is consistent since it rewrites the metadata of all images, and unfortunate as one wants to use this menu item to clean up the metadata. This does not seem to be a "straightforward" bug in Exiv2, as the problem does not occur under linux, it is specific to OS X. The apparently random occurrence may suggest some kind of overflow error. Is the bug necessarily in Exiv2, could it be in digikam?
This is a good question. The DK implementation is a high level wrapper to preapre metadata to write a good place. It's Qt code, mostly portable as well.. Al low level operations are managed at end by Exiv2. If the problem become on access to files, well, this can be an Exiv2 dysfunction. To investiguate, if you are able to reproduce the problem easily, is to run DK from a console. The binary is : /opt/digikam/Applications/KF5/digikam.app/Contents/MacOS/digikam Just run it and catch all the debug statements printed on the console when problem occurs. Gilles Caulier
I gave the console error messages in the initial description, but I will upload a full console log asap. It seems to me that those error messages don't tell us whether the problem is a bug in Exiv2, or if digikam is providing bad data to Exiv2 (only occasionally of course). We would need digikam to print out the data each time it calls Exiv2.
I have run a couple of examples using 100 copies of the same jpg image, i.e. $ for i in {0..99}; do cp image.jpg test/image$i.jpg; done I will upload relevant files following this message.
Created attachment 103079 [details] Console log showing metadata writing to image files.
During that run, metadata was not correctly written to 7 images: image0.jpg, 3, 9, 12, 26, 38, 87. All others were written correctly.
Created attachment 103080 [details] The original test image.
Created attachment 103081 [details] image0.jpg - shows incomplete metadata
Created attachment 103082 [details] image1.jpg - shows complete metadata
Created attachment 103083 [details] Console log showing metadata writing to sidecars. During this run, the sidecars for 5 images were truncated: image12.jpg, 24, 36, 76, 81. All the other sidecars were correctly written (as far as I can tell).
Created attachment 103084 [details] image12.jpg.xmp - shows a truncated sidecar
Created attachment 103086 [details] image0.jpg.xmp - example of a complete sidecar
Did you set a configuration to write comment to ACDSEE XMP namespace ? digikam.metaengine: Will write Metadata to file "/Users/test/Pictures/test/image0.jpg" digikam.metaengine: xmlACDSee "<Categories><Category Assigned=\"1\">blabla</Category></Categories>" digikam.general: -------------------------- New Keywords ("blabla") Gilles
Not to my knowledge. I set up a test account and started up digikam with a
Not to my knowledge. I set up a test account and started up digikam with a clean config, just changing the image/sidecar metadata settings.
I just did a test by starting up digikam without a digikamrc file and accepting the default setup options. By default metadata writing is deactivated, but all the options on the metadata->Advanced tab are selected (so they become active when metadata writing is turned on).
Dear Gilles, Maik and other maintainers I'm very very very pleased to report that digiKam-6.0.0-beta3-20181208T124813-MacOS-x86-64.pkg does not display this Mac-specific metadata-writing bug. It was present in all previous versions I tested up to 6.0.0-beta2 of 15th October. (I did not test any build of beta3 before 8th Dec.) Could you please comment on whether this is due to a fix or to chance? Are you aware of a change in code or in the MacOS build process between beta2 15 Oct and beta3 8 Dec which may have affected this behaviour? Thanks very much Philip
Thanks for your feedback. I close this file now... Gilles Caulier