Bug 331912 - face detection and recognition dos not work, tags and factags counts for one person are different, memory goes up and up without any result
Summary: face detection and recognition dos not work, tags and factags counts for one ...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Recognition (show other bugs)
Version: 3.5.0
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-09 13:19 UTC by G.Rass
Modified: 2019-12-23 07:40 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description G.Rass 2014-03-09 13:19:22 UTC
First I cleared for one person the difference of counts in face tags (100) and tags (104) to 104 face tags. Doing this cased to fill the memory to no limit, so i killed digiKam.
Then I restarted digikam and tried to find more faces, but the memory filled up again. (I did it all with valgrind this time)

Reproducible: Always

Steps to Reproduce:
1. ad a face tag
 or start detecting faces
Actual Results:  
It not possible to us digikam without killing it and restarting the program. sometimes digikam remains in the process table although the window closed with killing.

Expected Results:  
Adding new face tags without filling up the memory, also with the automatic face detection.

I think the database can not deal with the difference of the tag of a person and the face tag of a person. 
Sometimes there is even the same face taged twice in one picture.

Valgrind:


==4621== 
==4621== 1,712 bytes in 2 blocks are possibly lost in loss record 26,227 of 26,933
==4621==    at 0x4C277AB: malloc (vg_replace_malloc.c:270)
==4621==    by 0x1E6388B6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E614D29: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E61C9B7: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E61C9DC: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E65124D: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E6948D6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x2B7B216E: ??? (in /usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==4621==    by 0x4E468A0: QSqlDatabase::open() (in /usr/lib64/libQtSql.so.4.8.5)
==4621==    by 0x783C3B0: Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&) (databasecorebackend.cpp:213)
==4621==    by 0x783C97C: Digikam::DatabaseCoreBackendPrivate::databaseForThread() (databasecorebackend.cpp:119)
==4621==    by 0x783EE82: Digikam::DatabaseCoreBackend::open(Digikam::DatabaseParameters const&) (databasecorebackend.cpp:768)
==4621== 
==4621== 1,728 bytes in 18 blocks are possibly lost in loss record 26,230 of 26,933
==4621==    at 0x4C277AB: malloc (vg_replace_malloc.c:270)
==4621==    by 0x1E6388B6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E614D29: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E61C9B7: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E61CAF0: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E61CB6C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E6219DA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E641B50: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E641C6B: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E641E1C: sqlite3_create_function_v2 (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E641E64: sqlite3_create_function (in /usr/lib64/libsqlite3.so.0.8.6)
==4621==    by 0x1E694BCB: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==4621== 
==4621== 1,728 bytes in 18 blocks are possibly lost in loss record 26,231 of 26,933
Comment 1 caulier.gilles 2014-03-09 13:59:32 UTC

*** This bug has been marked as a duplicate of bug 323888 ***
Comment 2 Maik Qualmann 2017-12-17 19:21:31 UTC
Git commit 6a9fd9891a3ff341dc42fe36158cbf0101d513b6 by Maik Qualmann.
Committed on 17/12/2017 at 19:20.
Pushed by mqualmann into branch 'master'.

delete threads from memory when they are finished
Related: bug 375317, bug 375035, bug 321784, bug 325712, bug 328732, bug 330227, bug 344661, bug 345395, bug 350549, bug 381877, bug 338249, bug 329651, bug 329091, bug 387821, bug 381222

M  +2    -1    NEWS
M  +25   -0    libs/database/dbjobs/dbjobsmanager.cpp
M  +35   -0    libs/iojobs/iojobsmanager.cpp

https://commits.kde.org/digikam/6a9fd9891a3ff341dc42fe36158cbf0101d513b6
Comment 3 caulier.gilles 2017-12-17 20:01:22 UTC
Following this commit:

https://commits.kde.org/digikam/6a9fd9891a3ff341dc42fe36158cbf0101d513b6

... the approach to fix this problem is under way and new digiKam 5.8.0 pre-release bundles will be compiled tonight to lets a chance to end-users to give a feedback about this fix before the 5.8.0 official release planed before Christmas 2017.

The bundles will be available in 2 hours at this url:

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

Please do not waste time to test if this file is always valid for next 5.8.0.

Thanks in advance

Gilles Caulier
Comment 4 caulier.gilles 2019-12-23 07:40:18 UTC
Problem is fixed with new 7.0.0-beta1 through this long story from this bug

https://bugs.kde.org/show_bug.cgi?id=399923

You can test digiKam 7.0.0-beta1 with bundle available here:

https://download.kde.org/unstable/digikam/

Don't hesitate to give us a fresh feedback about his entry.

Thanks in advance

Gilles Caulier