https://bugs.kde.org/show_bug.cgi?id=468830
--- Comment #13 from Darek Kay <m...@darekkay.com> --- @Maik Thank you for looking into this. I should have been more specific: it is not the XMP file that is destroyed (here digiKam always works). It's the JPG file for which the sidecar exists that is destroyed. This is the setup: - 468830-small.jpg + 468830-small.xmp - 468830-big.jpg + 468830-big.xmp Here are the settings you've requested - ☑ Read from sidecar files - ☑ Write to sidecar files; Write to XMP sidecar for read-only item only - ☑ Sidecar file names are compatible with commercial programs I also use: ☑ Behavior: Delegate to ExifTool backend all operations to write metadata to files After changing the rating to "2" for both files, digiKam displays values from the sidecar file (rating 5). Inspect the JPG files manually to verify the problem: $ exiftool -Rating 468830-big.jpg <no result> $ exiftool -Rating 468830-small.jpg Rating : 2 And it's not only the rating that is missing for "big.jpg", it's the entire EXIF/XMP/IPTC metadata. Some further notes: - I've installed 8.2.0 after my comment yesterday and the issue is still reproducible. - I'm on Windows 10. As the workaround from José is not practicable for my use case (I would have to remove information from the XMP file), I will probably adjust my workflow. Right now I'm using "file.jpg" + "file.raf" + "file.xmp" (and hence the settings I've listed above), but I really only want to use XMP for the RAW file. As the (from my perspective) unintended JPG<>XMP connection causes the problem, I might use "file.jpg" + "file.raw.raf" + "file.raw.xmp" as a workaround, for which this bug does not occur. I hope this helps others with a similar setup. -- You are receiving this mail because: You are watching all bug changes.
