SUMMARY *** Digikam doesn't write metadata to files/sidecars under unclear circumstances *** STEPS TO REPRODUCE 1. Change any meta data, eg. tags, apply and save then changes. 2. Check if the file itself or the XMP sidecar was modified. OBSERVED RESULT Chnages are wirtten to database but either nothing else happened with both files (DK 8.0.0 on Kubuntu) or only the sidecar was updated (DK 8.0.0 on MacOs 10.15). Please note: On a 2nd Kubuntu as well as a 2nd MacOs installation everything runs fine as expected. All systems have the same preferences and exiftool is working on each of them. Tried to disable exiftool delegation on both not working systems without any luck. Tried as well whether the issue is related to DNG files only, but it's the same with JPGs. I can definitely exclude permission problems. EXPECTED RESULT Both the DNG and the XML sidecar should be modified as specified in preferences and working in previous versions. SOFTWARE/OS VERSIONS Windows: macOS: 10.15 Catalina (but working fine on 2nd machine with same system) Linux/KDE Plasma: Kubuntu 22.04 (but working fine on 2nd machine with same system) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3
Try with last 8.1.0 just released. Under Linux use the AppImage bundle that we provides. Gilles Caulier
Take screenshots of the metadata and sidecar settings. In DNG files only metadata is written with enabled ExifTool for writing and DNG option enabled. Maik
Created attachment 160661 [details] DK 8.0.0 setting 'Behaviour'
Created attachment 160662 [details] DK 8.0.0 setting 'Sidecars'
Created attachment 160663 [details] DK 8.0.0 setting 'Exiftool'
Created attachment 160664 [details] DK 8.1.0 setting 'Exiftool'
First of all: Forget the MacOS issue. While starting with the requested screenshots I detected a wrong setting: Delegate to Exiftool was not checked. Checking it immediately led to proper working of the MacOs version. Sorry – my bad! The Linux/Kubuntu issue seems to be bit more tricky. Running 8.1.0 from an Appimage works as expected – both files are written. Unfortunately the Snap store is pretty sleepy, so I assume they won't update DK before Christmas or so. Interesting question ist, why the same version 8.0.0 is running fine on another machine with all in all the same Linux system. I suspect Exiftool being tangled somehow. What I've noticed: In 8.0.0 there is Exiftool 12.40, in 8.1.0 it's Exiftool 12.62. As far as I know, Exiftool is an external source to which Digikam depends. Does that mean there are two versions running on the system or is 12.62 included to the Appimage? Running 'exiftool' in the terminal responses 'Syntax: exiftool [OPTIONS] FILE Consult the exiftool documentation for a full list of options.' while on the 'good' Linux machine a proper manual appears with the same command. ('whereis exiftool' responds '/usr/bin/exiftool /usr/share/man/man1/exiftool.1p.gz' on both machines). When I disable 'Delegate to exiftool' in 8.0.0, at least the XMP sidecar gets written, when enabling the option again, nothing at all is written to any file. Clicking on 'Change' in the Exiftool panel of the metadata settings easily locates Exiftool in /bin in 8.1.0, whereas 8.0.0 (on both Linux machines) shows nothing, neither in /bin nor in /usr/bin. From my perspective it's not easy to understand what's going on here, since Exiftool 12.40 is clearly located in /usr/bin.
Yes, ExifTool is in AppImage bundle. But we also look for ExifTool in the system, we may need to change this related to AppImage. Another problem is using Lazy Sync and re-reading metadata from the file when changes are made. We cannot guarantee in all cases that changes made will be rolled back with a re-read, as some plugins do this because they do not have a database frontend (because of Showfoto). We made the Geolocation Editor compatible with Lazy Sync for digiKam-8.2.0, with a pure database interface. Lazy Sync: I wouldn't use it. Re-read Metadata: Only needed if you change images externally. Maik
Beside the fact that I really like the 'Lazy Sync' and the 'Re-read Metadata' functions and never had any problems with them (yes, I'm working with external tools too), I deactivated both for test purposes but that didn't solve the problem. As a workaround I will avoid metadata changes on the bad machine and use one of the good ones instead. Anway: Thanks for your help!
Ralf S, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
The 8.2.0 AppImage is running fine, the described error doesn’t occur anymore. As I mentioned, it was gone already in AppImage 8.1.0 and meanwhile I'm running the snap version of 8.1.0 on the »bad« machine without this error too. So from my point of view everything’s looking great – thank you!
Thanks for the feedback. Closed.