Created attachment 135688 [details] People View with "People" parent tag SUMMARY Some tags appear beneath "People" parent tag in People view/panel STEPS TO REPRODUCE 1. Clean install of 7.2.0-rc (ffbcb5f3) 2. Run Face Detection and Recognition 3. Open "People" view OBSERVED RESULT - Refer to attached screenshot. - Noticed in People view there is a parent tag (with face icon) named "People" with Unconfirmed, Unknown and Ignored tags as well as names underneath. Did not see this on prior builds. There are also names in the root (not under the "People" tag). - I attempted to move some of the tags under People but they reappear under the root when re-launching digiKam. - Installed latest 2/12/2021 (de41d0b2) build and issue still persists. EXPECTED RESULT - Did not notice this behavior in prior builds. - No "People" parent tag, simply the people names. SOFTWARE/OS VERSIONS Windows 10
The people parent tag is by design, it has always been there. The people tag is created automatically if it doesn't exist. If a parent tag exists that has most of the face tags under it, it will not be created. You can move the face tags outside of the people tag to the people tag. This people tag has been discussed for a long time and we have some bug reports about it. Maik
One more explanation and I've read your post in user list. The People Tag was created to keep the tags in order. The standard does not provide a path for face tags. Therefore, found face tags from digiKam are tried to combine them under the people tag. This does not always work, if the scanner scans images first and keywords contain the names of later face tags, these are created outside of the people tag. In any case, you can move face tags to the people tag (drop them on people tag and choose move). If this does not work, your database tags tree is corrupted... Maik
Thanks Maik. Moving the tags within the "People" view as well as using the Tag Manager, but when I restart digiKam they returned to the previous locations. Typically, I do not store people's names in my tags/keywords- only in MS Windows Photo Gallery People Tags. However, I discovered that some of the affected photos had tags in the tag/keyword metadata. I deleted these tags in Windows Photo Gallery and moved the tags in digiKam again and this time it worked. digiKam moved them to its People/<name goes here> structure. Could it be that given I do not have the setting enabled in digiKam to write the metadata back to the file that digiKam re-reads the metadata on restart and gives precedent to the file metadata? I will do some testing around this.
I take my previous comment back, after another restart of digiKam the tags returned back to the previous locations not under the "People" parent tag.
Created attachment 135703 [details] Sample Image I did a clean install with a clean MySQL db and narrowed the steps to reproduce this issue. 1. Load attached sample image into digiKam Album - this sample image has a MS WPG People Tag "Albert Einstein" as well a keyword/tag "Albert Einstein". 2. Note people tag "Albert Einstein" created below special "People" tag 3. Move "Albert Einstein" tag beneath "People" tag 4. Close digiKam 5. Open digiKam Encountered Behavior: - Tag return to previous state, at the same level as "People" tag
No, the problem definitely does not occur here, also MySQL tested. Install Microsoft's DebugView, activate the debug environment variable and post the log if you move the tag. DebugView is described here: https://www.digikam.org/contribute/ Maik
Do you use the internal MySQL server? Maik
Git commit 8255cb9325deec0a9c95c3621266e536981a2e68 by Maik Qualmann. Committed on 15/02/2021 at 22:04. Pushed by mqualmann into branch 'master'. use "mysqladmin shutdown" to stop MySQL server The call via terminate() does not work for Windows console programs. With kill() at end, so we have data loss in the database under Windows. M +21 -0 core/libs/database/server/databaseserver.cpp https://invent.kde.org/graphics/digikam/commit/8255cb9325deec0a9c95c3621266e536981a2e68
I am using Remote Server (MySQL). Based on your recent comment seems you managed to stomp out the bug. Go Maik! Looking forward to the next available rc build with the fix to test it out.
No, the last patch tries to fix the problem with the internal MySQL server, which is completely managed by digiKam, which results in destroyed database tables. The problem does not affect an external MySQL server. I need the DebugView log from comment 6. Maik
Created attachment 135719 [details] DebugView logs Attaching DebugView Logs - digilog_move_tag.txt - Opening Digikam, moving "Albert Einstein" tag to people tag in Tag View. - digilog_move_people_tag.txt - Opening Digikam, moving "Albert Einstein" tag to people tag in People View.
I already suspected that something is wrong with your database, namely with the new triggers for the TagsTree. What are you using, MySQL or MariaDB? Which MySQL Server Version? It looks like the TagsTree doesn't exist, did you update or re-create the database? The fact is, with this malfunction, the tags management will be not work. Maik
According to the error message, it is MySQL. That will be difficult because we are only testing with MariaDB and MySQL is no longer available as a package. Maik
MySQL 8.0.23 I first came accross this issue when I created the MySQL db, I deleted it and recreated the database to try to narrow this issue down and it still occurs.
Yes, I can confirm that the issue also affects "regular" tags which cannot be moved either.
I installed MariaDB and was able to move the tags into the People tag. Closing and re-opening Digikam, and the changes persists, confirming the functionality worked as expected. So it may seem to be an issue with MySQL in Windows.
Git commit 1d23c88ca41660d548e2bdf2136c9d4bfda5cbd3 by Maik Qualmann. Committed on 16/02/2021 at 18:26. Pushed by mqualmann into branch 'master'. wrap in SELECT clause for MySQL M +10 -6 core/data/database/dbconfig.xml.cmake.in https://invent.kde.org/graphics/digikam/commit/1d23c88ca41660d548e2bdf2136c9d4bfda5cbd3
The problem is MySQL. With DELETE it cannot read from the same table in the WHERE clause. Please test the change, if it is available with MySQL, whether the moving of tags works there as well. A new DB must be created. Maik
Trigger now works fine on MySQL-8, tested in a Windows 10 VM. Maik
Fixed: Able to move tags, changes persist after closing and re-opening digiKam. Tested on 7.2.0-rc (46fd680f) 2/16/2021 build with MySQL 8.0.23 on Windows 10.