Summary: | Duplicate tags keep reappering at their old places in hierarchy | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | † <myaccount132> |
Component: | Tags-Captions | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | metzpinguin |
Priority: | NOR | ||
Version: | 7.7.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 7.8.0 | |
Sentry Crash Report: |
Description
†
2022-08-18 13:47:29 UTC
Bug 457682 or Bug 454676 fixes the tags disappearing or possibly reappearing due to a scanning process when moving images. Maik This still happened. I'm now using 8.4.0. appimage but it started possibly already with 8.3.0. If tags reappear, they are still present in the image metadata, this is not a digiKam bug, but normal behavior. Deleted tags cannot simply reappear, they must be present in images or sidecars. Maik So it's normal behavior if I've several times removed those tags from all images they were attached, and according to UI they disappeared from all those images, still time after time they keep coming back from those images they were removed. The tags were probably not completely removed from the images. There are some tag metadata that digiKam cannot change or delete with Exiv2. These are the Exif XP* entries. These are only changed if writing with ExifTool is activated. Maik See https://bugs.kde.org/show_bug.cgi?id=492163 for possible cause. This is not fixed as in some cases there's inconsistent data written to two sidecars in different locations. See https://bugs.kde.org/show_bug.cgi?id=492163 Sidecars in 2 different locations have nothing to do with the bug, as long as there is no image with the same base name the sidecar is ignored. If you want to reopen the bug, then only if you provide an image and sidecars with which the problem can be reproduced. Maik Files attached to https://bugs.kde.org/show_bug.cgi?id=492163 as I haven't tested but only suspecting they cause this bug too. I tested this. Your previous answer is simply wrong and this bug is related and explained at least in some cases with https://bugs.kde.org/show_bug.cgi?id=492163 If database data is ovewritten with data from faulty sidecars which contain tags which are deleted later, those tags will return. See also Comment 6 at bug https://bugs.kde.org/show_bug.cgi?id=492163#c6 1. First add tags to image and apply them. 2. Unselect those tags (and optionally add some other tags), don't apply changes, keep selection 3. Move files to different folder. (Now by UI those unselected tags are removed from file and optional new tags are added.) 4. Delete those tags added at 1. and removed from file at 2. altogether from system. Nothing visible in regard to file itself should happen as they were already removed from there, but they disappear from tag list. 5. Select "Reread metadata from file". Result: Phase 2. is cancelled: By UI original tags from 1. are returned to file and optional new tags at 2. are removed from file. Also: TAGS REMOVED FROM SYSTEM at 4. RE-APPEAR TO TAG LIST which is this bug. It is clear that if you do not complete the action on the right sidebar and move the images, then a sidecar will be created in the "old" location. We already have an older Bug 204487 for this, it continues there. This is closed. Maik This bug could be duplicate but it's not fixed. You corrupt peoples minds with this kind of behavior. |