Under certain conditions, inconsistent face assignments cannot be automatically resolved by the background worker, which can result in an unusually high CPU load when it is running:
- if you use multiple browser tabs or windows for assigning faces and don't wait until saving the changes is complete, the likelihood of this problem increases, especially if you accidentally enter different names for the same face
- another possible cause is running multiple instances (for example, parallel indexing workers started by a scheduler in the background) or modifying database content directly, as this may also lead to inconsistent faces, markers and subjects
Running the following command in a terminal can resolve problems with inconsistent data:
docker compose exec photoprism photoprism faces audit --fix
It can also be helpful to manually check for inconsistent assignments and fix them in the user interface. Alternatively, you can use the photoprism faces reset command for a clean start if you haven't invested much time in assigning faces yet.
Advanced users affected by this are welcome to privately provide us with a SQL dump of their subjects, faces, and markers database tables for debugging. Thank you very much!
1. What is not working as documented?
If there is an error of "faces: failed removing merged clusters for subject (ID)",
tagging any new faces becomes incredibly slow normally 1-3 seconds, now 2-5 minutes.
This behavior happens wether tagging a random photo through photo browser or a "new face" collection under People.
2. How can we reproduce it?
I don't know how to reproduce this error, but this is the second time that it has occurred.
The first time, I tried a bunch of a few recommendations like increasing the innodb buffersize but they didn't fix the problem.
Resetting the Face ID allowed me to tag quickly again (although it meant starting over) and it worked great over the next 60,000 photos.
Now the same error is back and the same lag is back.
Steps to reproduce the behavior:
I don't know how to FORCE the error to be created.
3. What behavior do you expect?
Some way to undo or stop the merge attempt. If a single failed removing merged cluster for a single subject can cause this much of a performance issue, make an undo button or better yet just automatically undo it. I don't know I'm just making up suggestions because I don't really know what the error means.
4. What could be the cause of your problem?
People have said this might be caused by Tagging the same person with a similar but different name. If that's true, great! It would be nice if Photo Prism stopped me from creating the conflict. or reverted the action once it realizes it is going to cause a conflict.
5. Can you provide us with example files for testing, error logs, or screenshots?
Here is a video I gave @lastzero when it happened the first time. https://1drv.ms/v/s!AjcUU9ZDJWosuu9yj-2Sf0U2_tD2tA?e=6r1SXm
6. Which software versions do you use?
(a) PhotoPrism Build Number: 220901-f493607b0
(b) Database Type & Version: MariaDB
(c) Operating System Types & Versions: Linux (Unraid + Docker)
Under certain conditions, inconsistent face assignments cannot be automatically resolved by the background worker, which can result in an unusually high CPU load when it is running:
Running the following command in a terminal can resolve problems with inconsistent data:
docker compose exec photoprism photoprism faces audit --fixIt can also be helpful to manually check for inconsistent assignments and fix them in the user interface. Alternatively, you can use the
photoprism faces resetcommand for a clean start if you haven't invested much time in assigning faces yet.Advanced users affected by this are welcome to privately provide us with a SQL dump of their subjects, faces, and markers database tables for debugging. Thank you very much!
1. What is not working as documented?
If there is an error of "faces: failed removing merged clusters for subject (ID)",
tagging any new faces becomes incredibly slow normally 1-3 seconds, now 2-5 minutes.
This behavior happens wether tagging a random photo through photo browser or a "new face" collection under People.
2. How can we reproduce it?
I don't know how to reproduce this error, but this is the second time that it has occurred.
The first time, I tried a bunch of a few recommendations like increasing the innodb buffersize but they didn't fix the problem.
Resetting the Face ID allowed me to tag quickly again (although it meant starting over) and it worked great over the next 60,000 photos.
Now the same error is back and the same lag is back.
Steps to reproduce the behavior:
I don't know how to FORCE the error to be created.
3. What behavior do you expect?
Some way to undo or stop the merge attempt. If a single failed removing merged cluster for a single subject can cause this much of a performance issue, make an undo button or better yet just automatically undo it. I don't know I'm just making up suggestions because I don't really know what the error means.
4. What could be the cause of your problem?
People have said this might be caused by Tagging the same person with a similar but different name. If that's true, great! It would be nice if Photo Prism stopped me from creating the conflict. or reverted the action once it realizes it is going to cause a conflict.
5. Can you provide us with example files for testing, error logs, or screenshots?
Here is a video I gave @lastzero when it happened the first time. https://1drv.ms/v/s!AjcUU9ZDJWosuu9yj-2Sf0U2_tD2tA?e=6r1SXm
6. Which software versions do you use?
(a) PhotoPrism Build Number: 220901-f493607b0
(b) Database Type & Version: MariaDB
(c) Operating System Types & Versions: Linux (Unraid + Docker)