Bug 508060

Summary: When adding a new collection, tags are not associated with images when using sidecars file and tags hierarchy
Product: [Applications] digikam Reporter: Mistermoonlight <spiderman110>
Component: Tags-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 8.7.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In: 8.8.0
Sentry Crash Report:
Attachments: metadata small test set

Description Mistermoonlight 2025-08-09 18:48:31 UTC
SUMMARY
Installer used: digiKam-8.7.0-Qt6-Win64.exe (official release) under windows 10. After installation, metadata configuration behavior "Write this information to the metadata" are all selected. Also "Rescan file when files are modified" is not selected (manual refresh). Sidecars file configuration "Write to sidecar files": write to XMP sidecar only selected. Anything else in metadata is default settings. In miscellaneous settings, behavior section, all setings above red message "Warning: These settings makes startup slower" are deselected. Initially there is no collection neither tags in the databases (from clean install).

The image files collection has sidecars files in the form of "basefile.ext.xmp" and the tags are fully qualified with tags hierarchy (using "/" character in the tags hierarchy). The tags are only located in the sidecars files, not in the images themselfves.
When creating a collection, the tags hierarchy is fully created in digikam, but no images at all will have a tag (selecting no tags in tag tab will show all images of the collection!).

The only  way i found to repair this problem after the collection was created is to do a database maintenance in the "Sync Metadata and Database" option, select it with sync direction "From image metadata to database", then magically all images are associated with their respective tags!

It is like when the collection is created, if the tag hierarchy does not exist, it cannot create the tag and associates it to the image at the same time. A second pass through the database maintenance is needed to do the job. correctly

The bug is fully reproductible all the time.

STEPS TO REPRODUCE
1. Start a clean digikam installation
2. Configure it as explained
3. Create a new collection with images using only external sidecar files for tags (using a fully qualified tag hierarchy)

OBSERVED RESULT
Not an image at all will be tagged, but the completly full tag hierarchy is created as expected, simply no image will be assigned to any tag

EXPECTED RESULT
The images are associated to their tags in the hierarchy immediatly when the collection is created the 1st time and does not require a database maintenance which appears to be a little dangerous to use everytime the files change in the collection to overwrite some database settings...

SOFTWARE/OS VERSIONS
Windows: 10
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 caulier.gilles 2025-08-09 19:11:22 UTC
Can you share few items to try to reproduce the dysfunction ?
Comment 2 Mistermoonlight 2025-08-09 19:25:12 UTC
I will try to provide something with few anonymous images...
Comment 3 Maik Qualmann 2025-08-10 07:36:01 UTC
I'm sure I can't reproduce it. This problem has been reported several times under Windows, where not all metadata is found during the initial scan. We suspect either a locked collection directory because other programs are accessing it at the same time, or a database lock issue.

If you can always reproduce it, please create a DebugView log as described here for Windows:

https://www.digikam.org/contribute/#windows-host

Please also test the pre-release digiKam-8.8.0 version, as we now also support long file paths, this can also be a cause:

https://files.kde.org/digikam/

Maik
Comment 4 Mistermoonlight 2025-08-10 19:32:27 UTC
Created attachment 183939 [details]
metadata small test set

I have build a small test set (attached), but i am not sure now that this is the same behavior of what i encountered first when i initially reported it. The behavior is different, maybe i wrongly understood it the 1st time. But i can still generate with the test set a similar problem i guess. When the test set is imported, it is creating the tags correctly i guess with the test set. Then i am going in the settings and delete the configured collection associated with the test set. Then i am going in the tag manager and choose all the tags and remove tags from images (should not do anything i guess, images are gone), then from there delete all the tags completly. Then in the maintenance menu, choose perform database cleaning and selects the 4 choice (full cleanup). So at this point, i am expecting that all tags are deleted, collection was deleted, database fully cleaned, so if i am creating the same test set collection again(attached) using the same directory path where is located the test set at the first time, i am getting the bug: the full hierarchy of the tags are created, but no image are associated to any tag! If i am doing a maintenance of the database again with reimports metadata from the files, it repair fully the problem and all images are becoming associated to metadata again. I am not quite sure if it is the same behavior as the original behavior or if there are mutiple possible ways to create this problem, but at least there is something wrong here that does not look as bad as i 1st reported. Different way to create the problem and maybe there are others? I guess the database has something bad after collection deleted, tag cleaning and maintenace full cleanup that is causing this behavior. Sorry guys for the misunderstanding about this problem...
Comment 5 Maik Qualmann 2025-08-11 07:46:18 UTC
Without having tested the test set at the moment, we do reuse deleted or "lost" items in the database once the item scanner has retrieved the file based on its UUID. The idea is to avoid unnecessary file rescanning. On second thought, this could be problematic in the case of sidecars. I'll investigate this further.

Maik
Comment 6 Maik Qualmann 2025-08-11 19:00:33 UTC
Git commit 656957227df040c2b206ea174b7987acfa244e05 by Maik Qualmann.
Committed on 11/08/2025 at 18:59.
Pushed by mqualmann into branch 'master'.

if reading sidecars is enabled ignore stale database images
FIXED-IN: 8.8.0

M  +1    -1    NEWS
M  +15   -13   core/libs/database/item/scanner/itemscanner_database.cpp
M  +12   -11   core/libs/database/item/scanner/itemscanner_p.h

https://invent.kde.org/graphics/digikam/-/commit/656957227df040c2b206ea174b7987acfa244e05