Bug 431497 - Unconfiremd Faces Counter has an Offset
Summary: Unconfiremd Faces Counter has an Offset
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Workflow (show other bugs)
Version: 7.2.0
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-12 13:25 UTC by kontakt+kde
Modified: 2021-05-23 16:35 UTC (History)
5 users (show)

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


Attachments
Screenshot (169.41 KB, image/png)
2021-01-12 13:25 UTC, kontakt+kde
Details
Screenshot 2 (46.74 KB, image/png)
2021-01-12 13:27 UTC, kontakt+kde
Details
Screenshot (170.49 KB, image/png)
2021-01-12 13:29 UTC, kontakt+kde
Details
Screenshot (46.86 KB, image/png)
2021-04-18 14:10 UTC, Michal Kec (MiK)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kontakt+kde 2021-01-12 13:25:16 UTC
Created attachment 134776 [details]
Screenshot

SUMMARY
The counter of unconfirmed faces is non-zero even if no unconfirmed faces are shown.

STEPS TO REPRODUCE
1. Got the offset probably during a crash on with beta1
2. Now I have a constant offset with on Three Identities.

OBSERVED RESULT
Counter is bigger than the actual number of unconfirmed faces

EXPECTED RESULT
Counter showing the number of unconfirmed faces

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: KDE Frameworks 5.74.0
Qt 5.14.2 (kompiliert gegen 5.14.2)
Das xcb Fenstersystem

ADDITIONAL INFORMATION
Comment 1 kontakt+kde 2021-01-12 13:27:01 UTC
Created attachment 134777 [details]
Screenshot 2
Comment 2 kontakt+kde 2021-01-12 13:29:36 UTC
Created attachment 134779 [details]
Screenshot
Comment 3 Maik Qualmann 2021-01-12 20:41:12 UTC
I can't quite understand where the problem is exactly. Go to the people with (2 new) or (1 new). There should be faces grouped with a green frame, either confirm or reject them.

Maik
Comment 4 kontakt+kde 2021-01-12 21:10:11 UTC
Sorry for being unclear.
The problem is that there are no unconfirmed faces shown. Neither in the 
Unconfirmed tag, nor within the corresponding person. There are only 
Confirmed faces shown.
Comment 5 Michal Kec (MiK) 2021-04-18 14:10:23 UTC
Created attachment 137684 [details]
Screenshot

I can confirm this bug with digiKam 7.2.0 (updated from 7.1.0 by Neon's DEB package).

People's tag:
- No faces with green frames.
- Incorrect number of new (unconfirmed) images (6 or 2)

Unconfirmed ("Nepotvrzeno") tag:
- No faces at all
- Incorrect number of containing images (2)


Operating System: KDE neon 5.21
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Kernel Version: 5.8.0-49-generic
OS Type: 64-bit
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: Radeon RX 580 Series

Using internal MariaDB server 10.3.25-0ubuntu0.20.04.1. Scheme gradually updated since digiKam 6.x.
Is it a database issue? Can I check and/or fix the counter issues with MySQL console?
Comment 6 Maik Qualmann 2021-05-03 15:13:52 UTC
Can you post the output in the terminal with the debug environment variable activated, as described here:

https://www.digikam.org/contribute/

When you click on the person with the two entries that you can't see?

Maik
Comment 7 Michal Kec (MiK) 2021-05-05 16:51:22 UTC
(In reply to Maik Qualmann from comment #6)
> When you click on the person with the two entries that you can't see?

Hello Maik, sure I can. Every time I click on the face tag "MiK", I get this log output:

digikam.geoiface: ----
digikam.geoiface: ----
digikam.general: Using  16  CPU core to run threads
digikam.general: Action Thread run  1  new jobs
digikam.database: " ( ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) OR ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) OR ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) OR ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) ) "
digikam.database: Search query:
 "SELECT DISTINCT Images.id, Images.name, Images.album,        Albums.albumRoot,        ImageInformation.rating, Images.category,        ImageInformation.format, ImageInformation.creationDate,        Images.modificationDate, Images.fileSize,        ImageInformation.width,  ImageInformation.height,        ImageTagProperties.value, ImageTagProperties.property, ImageTagProperties.tagid  FROM Images        INNER JOIN ImageTagProperties ON ImageTagProperties.imageid=Images.id        LEFT JOIN ImageInformation ON Images.id=ImageInformation.imageid        INNER JOIN Albums           ON Albums.id=Images.album WHERE Images.status=1 AND (  ( ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) OR ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) OR ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) OR ( ImageTagProperties.tagid=? AND ImageTagProperties.property=?  ) )  );" 
 (QVariant(int, 22), QVariant(QString, "autodetectedPerson"), QVariant(int, 22), QVariant(QString, "autodetectedFace"), QVariant(int, 22), QVariant(QString, "ignoredFace"), QVariant(int, 22), QVariant(QString, "tagRegion"))
digikam.geoiface: ----
digikam.database: Search result: 4585
digikam.general: Cancel Main Thread
digikam.general: One job is done
digikam.general: Cancel Main Thread

I can get almost the same output by clicking on the tag "Nepotvrzeno" (unconfirmed) - just the tag numeric id is 254 (and the search result is different too).

BTW: The numbers are changing while I tag another photos. Tag "MiK" is currently showing "1 new" and tag "unconfirmed" three.

Is this log selection enough for you, or do you need to see full log output?
Comment 8 tlangner+kde 2021-05-08 14:51:09 UTC
I can confirm this problem. It looks like it has to do with dangling entries in the database. This problem is particularly annoying as face tags with an unconfirmed count > 0 appear first in the list of tags, making it difficult to find them when one searches alphabetically.

Would be nice if this bug is fixed.

Since I got a bit annoyed by this, I played around and found a rather ugly fix. It involves meddling with digiKam's database directly, which can possibly mess up things, so please only follow the steps if you know what you are doing, be careful and make a backup before you try this.

1) Close digiKam to prevent any concurrent modification of the database. Potentially unnecessary but does not hurt.
2) Create a copy of the file digikam4.db in your database directory.
3) Open digikam4.db with a sqlite DB editor, I use sqlitebrowser.
4) Run the following query on the database to check whether the counts correspond to the wrong unconfirmed counts in the app:

SELECT name, COUNT(*) FROM ImageTagProperties AS itp LEFT JOIN Tags AS t ON itp.tagid = t.id WHERE property = 'autodetectedPerson' GROUP BY name;

If that is the case, run the following query to get rid of them.

DELETE FROM ImageTagProperties WHERE property = 'autodetectedPerson'

If I understand the database contents correctly, entries in this table with that property represent unconfirmed faces, which are exactly what we want to get rid of.

After I run those steps, the unconfirmed counts return to zero as they should.
Comment 9 caulier.gilles 2021-05-08 14:58:33 UTC
Thanks tlangner for your investiguations.

Did you double check with current 7.3.0 pre-release, just to see if this problem already exists ?

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

Best

Gilles Caulier
Comment 10 caulier.gilles 2021-05-08 14:59:36 UTC
already exists -> always exists...
Comment 11 Maik Qualmann 2021-05-23 15:50:38 UTC
Git commit 9d783a36c298c748d897b630123c1e0679908bec by Maik Qualmann.
Committed on 23/05/2021 at 15:49.
Pushed by mqualmann into branch 'master'.

prevent delete and merge of required face tags
FIXED-IN: 7.3.0

M  +17   -1    core/libs/album/manager/albummanager_talbum.cpp

https://invent.kde.org/graphics/digikam/commit/9d783a36c298c748d897b630123c1e0679908bec
Comment 12 Maik Qualmann 2021-05-23 15:57:18 UTC
The problem can occur if the tags for unconfirmed or unknown have been deleted in the meantime. The system automatically creates new ones, but then the entries in the database of the "autodetectedPerson" no longer match. This patch prevents the accidental deletion of the required face tags. The database must be cleaned up as described in comment 8.

Maik
Comment 13 Michal Kec (MiK) 2021-05-23 16:35:58 UTC
(In reply to Maik Qualmann from comment #12)
> The database must be cleaned up as described in comment 8.

Hi Mike, thanks for your patch!

Based on comment #8, I've used following two queries to clean my DB:

-- clean all occurrence of the "unconfirmed" tag
DELETE FROM ImageTagProperties WHERE property = 'autodetectedPerson'

-- clean "new unconfirmed face" for persons' tags
DELETE FROM ImageTagProperties WHERE property = 'autodetectedFace' AND tagid<>255;

My issue shown at attachment 137684 [details] is now fixed.