| Summary: | Tags end up appearing withing another hierarchy where they don't belong | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Maintenance-Metadata | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, iwannaberich, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 7.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 8.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Tag hierarchy that appears in digikam after re-scanning
Affected picture (IMG_20211125_182631.jpg) Tag hierarchy for provided photo, according to digikam |
||
|
Description
MarcP
2021-12-04 04:42:07 UTC
This is what I see in the XMP metadata panel in digikam for one of the affected pictures: File name: IMG_20211125_182631.jpg (XMP Schema) >>> ACDSee XMP Schema <<< Categories : <Categories><Category Assigned="0">Llocs<Category Assigned="0">EEUU<Category Assigned="0">Massachusetts<Category Assigned="0">Berkshire County<Category Assigned="1">Sheffield</Category></Category></Category></Category></Category><Category Assigned="0">Esdeveniments<Category Assigned="1">Thanksgiving</Category></Category></Categories> >>> Adobe Lightroom Schema <<< Hierarchical Subject : Llocs|EEUU|Massachusetts|Berkshire County|Sheffield, Esdeveniments|Thanksgiving >>> digiKam schema <<< Tags List : Llocs/EEUU/Massachusetts/Berkshire County/Sheffield, Esdeveniments/Thanksgiving >>> Dublin Core <<< Subject : Sheffield, Thanksgiving >>> mediapro <<< Catalog Sets : Llocs|EEUU|Massachusetts|Berkshire County|Sheffield, Esdeveniments|Thanksgiving >>> Microsoft Photo <<< Last Keyword XMP : Llocs/EEUU/Massachusetts/Berkshire County/Sheffield, Esdeveniments/Thanksgiving Created attachment 144196 [details]
Tag hierarchy that appears in digikam after re-scanning
Created attachment 144197 [details]
Affected picture (IMG_20211125_182631.jpg)
Created attachment 144198 [details]
Tag hierarchy for provided photo, according to digikam
Based on the example image, I cannot find any errors. We have assigned 2 tags in the metadata with a tree structure: Llocs / EEUU / Massachusetts / Berkshire County / [x] Sheffield Esdeveniments / [x] Thanksgiving Maik I have been running some tests with a clean database and one isolated picture, and the keywords appeared correctly in the tag tree. I have not been able to isolate the behavior yet. However, no matter how many times I re-read the metadata in my main database, the "Esdeveniments/Thanksgiving" always ends up appearing withing "Berkshire county". I'll keep trying to see if I find something out. Wait, re-reading the metadata in the appimage seems to put tags back into place. However, that was not the case with the flatpak build. Does that make any sense? (Btw, the latest appimage is from 18/11/2021, digiKam-7.4.0-20211118T131744-x86-64.appimage, but the latest flatpak was compiled yesterday, I don't know if that would make a difference) If I see it correctly in your screenshot, you have 23 images with this wrong structure. You have to clean up these imgaes ... Llocs / EEUU / Massachusetts / Berkshire County / Esdeveniments / [x] Thanksgiving (23) Maik Oh, this is what I mean. These 23 pictures have the same exact metadata as the one I attached to this bug. The metadata seems to be correct in the pictures (according to the metadata panel), but digikam reads it incorrectly and places the "Esdeveninents / Thanksgiving" tags where they don't belong. And for some reason that I can't explain, if I re-read the metadata using the appimage version, the tags go back to their place. The only change we have that could be a cause is this function: https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/tags/tagscache.cpp#L567 The change came from an external developer and also led to the lock problem when writing tags. The change fixed a possible incorrect tags path. See https://bugs.kde.org/show_bug.cgi?id=432761#c8 I debugged the function again today and can't think of any mistakes. If this could only be reproduced with the Flatpak it would be very strange. Maik Maik, This can be a compiler option to optimize code while compiling the flatpak bundle. If the problem is not reproducible with the AppImage bundle (it have been recompiled today with current code), well this can be the problem. AppImage is compiled with GCC 8. If the Flatpak is compiled with GCC 10 and later, this can be the source. I read recent reort from MXE project where Qt compiled with a too much recent version of GCC introduce severe dysfunctions. Gilles I will try tomorrow with the new appimage once it's available and see if it behaves differently compared to the 21-Nov-2021 appimage. Marc, AppImage bundle is up to date at usual place... Gilles I tried it now, but I couldn't replicate it with any of the versions I have installed (7.3, and 7.4 in appimage and flatpak). I feel it only happens when you have just tagged a batch of images for the first time, and then the metadata is re-read from those pictures. If you want, we can leave this issue on the back burner for now and I'll try to gather more proof the next time it happens. The cause was a problem in the tags cache, which has now been fixed. Maik |