Bug 446458 - Tags end up appearing withing another hierarchy where they don't belong
Summary: Tags end up appearing withing another hierarchy where they don't belong
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Maintenance-Metadata (show other bugs)
Version: 7.4.0
Platform: Flatpak Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-04 04:42 UTC by MarcP
Modified: 2022-11-21 07:32 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.0.0
Sentry Crash Report:


Attachments
Tag hierarchy that appears in digikam after re-scanning (57.40 KB, image/png)
2021-12-04 04:44 UTC, MarcP
Details
Affected picture (IMG_20211125_182631.jpg) (3.16 MB, image/jpeg)
2021-12-04 04:45 UTC, MarcP
Details
Tag hierarchy for provided photo, according to digikam (41.38 KB, image/png)
2021-12-04 04:48 UTC, MarcP
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2021-12-04 04:42:07 UTC
SUMMARY

I have noticed something strange after tagging groups of pictures. Sometimes some tags appear within another tag when re-reading them into digikam. I thought that maybe it was my mistake while tagging some files, but I have observed this effect several times for the last couple of months and I right now I have been able to replicate it.

Basically, you tag some files. Metadata is written to the file and to the database, and apparently everything is ok. However, if you re-read the metadata in those pictures (or they are scanned from another computer), some of the tags appear as subtags of a recently-used tag. 

I have attached a screenshot. Today I tagged a group of pictures with two hierarchies:
Events / Thanksgiving
Places / USA / Massachusetts / Berkshire county

However, when re-scanning the files, the hierarchy Events / Thanksgiving appeared inside "Berkshire county".
 
What is weird, is that if you examine the XMP metadata, everything seems fine. Maybe the problem is in how digikam interprets the existing tags? This bug is relatively recent, I don't know if it happened in digikam 7.3

STEPS TO REPRODUCE
1. Tag some new pictures with two hierarchical tags
2. Wait until metadata is written to the files
3. Select those files and, re-read the metadata from files.

OBSERVED RESULT
Some tags appear within other tags

EXPECTED RESULT
The tag hierarchies that were written to the files should remain.

SOFTWARE/OS VERSIONS
Digikam 7.4 Build date: 3/12/21 10:27 (target: Debug)
Rev.: 981f041a8a0e9d082fff8923adf5b91b6ee2b4f9
Ubuntu 20.04.3 LTS
Comment 1 MarcP 2021-12-04 04:43:19 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
Comment 2 MarcP 2021-12-04 04:44:00 UTC
Created attachment 144196 [details]
Tag hierarchy that appears in digikam after re-scanning
Comment 3 MarcP 2021-12-04 04:45:08 UTC
Created attachment 144197 [details]
Affected picture (IMG_20211125_182631.jpg)
Comment 4 MarcP 2021-12-04 04:48:02 UTC
Created attachment 144198 [details]
Tag hierarchy for provided photo, according to digikam
Comment 5 Maik Qualmann 2021-12-04 07:12:00 UTC
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
Comment 6 MarcP 2021-12-04 16:06:21 UTC
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.
Comment 7 MarcP 2021-12-04 16:10:40 UTC
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?
Comment 8 MarcP 2021-12-04 16:14:56 UTC
(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)
Comment 9 Maik Qualmann 2021-12-05 11:43:27 UTC
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
Comment 10 MarcP 2021-12-05 14:43:22 UTC
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.
Comment 11 Maik Qualmann 2021-12-05 15:04:14 UTC
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
Comment 12 caulier.gilles 2021-12-05 18:47:14 UTC
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
Comment 13 MarcP 2021-12-05 18:56:04 UTC
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.
Comment 14 caulier.gilles 2021-12-05 20:13:14 UTC
Marc,

AppImage bundle is up to date at usual place...

Gilles
Comment 15 MarcP 2021-12-05 22:39:18 UTC
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.
Comment 16 Maik Qualmann 2022-11-21 07:32:48 UTC
The cause was a problem in the tags cache, which has now been fixed.

Maik