| Summary: | Tag's aren't being removed from images. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | ben+kde |
| Component: | Tags-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 7.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed/Implemented In: | 8.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
A sample image that produced the effect
Attempting to save Second example attachment DebugLog1 Another log |
||
The "H" tag can be removed here without problems, tested on Windows. Was the image open in other programs (Explorer) or part of a Windows network share? Download and start DebugView from Microsoft. Enable internal debugging in the digiKam Settings under Miscellaneous-> System and restart digiKam. Try deleting the tag and posting the debug output from the DebugView window. Maik Oh, I tested it with digiKam-8.0.0. Your tag is an XP keyword tag, this tag is a read only tag in Exiv2 and in digiKam-7.x.x. The XP keyword tag can only be written with digiKam-8.0.0 and activated ExifTool support. Maik Thanks for looking into this so quickly Maik! That was impressive identification as I did not notice that difference at first. So I upgraded to 8.0.0, and since you were able to do it I assume it's possible, however, for those jpgs, with exiftool enabled and sidecar write turned on only for read-only files, it seems to be writing changes to the sidecar xmp instead of the jpg itself. Is there a reason for this? Your tag still hasn't been deleted? You really have write support enabled in the metadata settings for ExifTool? Check if there is an entry for "Exif.Image.XPKeywords" in the advanced metadata settings under Tags. If not, use the Reset to Defaults button. The entry was added in a digiKam-7.x.x version, but we don't reset it automatically, because some users make very specific settings to share metadata with other programs. Maik Created attachment 156132 [details]
Attempting to save
I have attached a sample of what I am doing. I had a slightly different metadata config, but reset to default to test this out. I have attached a screen recording of what I am doing and the file properties before and after. The files and tags do eventually populate back into the digiKam tag list, but usually only after "Find new items" or restarting digiKam or such.
I have split the gifs into two files to get under the file size limit
Created attachment 156133 [details]
Second example attachment
I can't reproduce it, the tag is removed here, I write in Comment 1 that the file must not be open in Explorer because it is locked under Windows and we don't get write access. Otherwise, please create the DebugView log from Comment 1. Maik Created attachment 156135 [details]
DebugLog1
In those gifs, all explorer tabs were closed (I just chopped out those frames of the gif to reduce the size) and it's still creating sidecar jpgs. I also popped open process explorer and checked for the file paths to help check that there wasn't a file lock on them.
I have attached a debug log. I deleted the tag around entry 00000437 and it started the sync.
ExifTool is not available, which digiKam-8.0.0 version are you using? Recommended from here: https://files.kde.org/digikam/unstable/ Otherwise set the path to ExifTool manually in the digiKam metadata settings, ExifTool is located in the digKam program directory. I will additionally disable the entry in the metadata settings if ExifTool is not available/running. [61668] digikam.metaengine: ExifTool path: "exiftool.exe" [61668] digikam.metaengine: Path to ExifTool: "" [61668] digikam.metaengine: ExifToolProcess::kill(): shutdown ExifTool instance... [61668] digikam.metaengine: ExifTool process cannot be started ( "exiftool.exe" ) Maik Git commit 301e22f8764e63ab3861eec82dc10745e2c3964e by Maik Qualmann. Committed on 10/02/2023 at 21:31. Pushed by mqualmann into branch 'master'. better check if exiftool is also running M +33 -27 core/libs/widgets/metadata/exiftool/exiftoolconfpanel.cpp https://invent.kde.org/graphics/digikam/commit/301e22f8764e63ab3861eec82dc10745e2c3964e Created attachment 156137 [details]
Another log
Thanks for pointing that out, that was not obvious. In the reinstall, apparently it wasn't pointed at the exiftool in the digikam dir anymore. Also, I just tried it again with the path fixed, and the debug seems to me to show it should be working? But the file still has the tag embedded in it as "N" so it seems like it might not be working to me still? Additionally, might be because of the debugging, but the sync took many minutes for so few files, maybe too many rescans are being triggered?
Grabbing the info from the about panel, but I have
Version 8.0.0-beta1
Build date: 12/8/2022 2:42 PM (target: RelWithDebInfo)
Revision: 32899a31edfa223faf99b012c03190c5260efb82
Branch: HEAD
Thanks for all your help so far! I get the struggle of debugging your applications and working with people, but I think you've been doing a great job and your responsiveness is impressive! Thank you!
Your digiKam-8.0.0 version is too old, support for XPKeyword was only added around 12/25/2022. ExifTool takes a surprisingly long time in your system, around 6-7 seconds. Furthermore, they really need album monitoring for external changes, this leads to unnecessary scans of the collection? If you don't really need to update to external changes at runtime, you should disable this monitoring in the collection settings. Maik |
Created attachment 156119 [details] A sample image that produced the effect When I remove a tag from some images (JPGs), I hit apply, and it seems to work, but then I check the properties on the image and it is not updated. As well, it will soon appear again back underneath that tag in digiKam. The files are not read-only, and they are jpgs (so the metadata is set to write to the file itself, not a sidecar).