Let me start by saying this is a new issue that'll summarize a closed, but still happening issue. I'm creating this new issue based on @lastzero 's comment.
1. What is not working as documented?
For faces that were not added automatically, tagging people manually is slow to extremely slow. With some photos or persons (unsure), it takes a few seconds only (rare) but once that issue happens, most of the time it takes in my case between 1 and 2 minutes to tag 1 person. I've decided recently to move all my photos to photoprism so I've got quite a lot already, and quite a lot more to come. I have more than a couple hundreds pictures with unrecognized faces waiting to be tagged, but I'm not able to wait 1 to 2 mn for each, it'd be unmanageable.
It's documented as a known issue. I have tried the command docker compose exec photoprism photoprism faces audit --fix but it didn't help fixing the issue.
2. How can we reproduce it?
I have no idea how exactly to reproduce this, but both @pjft and myself have shared parts of our database by email directly to help debug it. See pjft comment and mine. Best case scenario it's enough to debug, if not I'm more than happy to provide more info.
3. What behavior do you expect?
When a face is detected but unknown, it shouldn't take more than a few seconds to add it manually.
4. What could be the cause of your problem?
Really unsure, sorry.
5. Can you provide us with example files for testing, error logs, or screenshots?
As stated above, this has been done by email as it includes personal data.
6. Which software versions do you use?
(a) PhotoPrism Architecture & Build Number: AMD64, ARM64, ARMv7,...
Build 221118-e58fee0fb
(b) Database Type & Version: MariaDB, MySQL, SQLite,...
MariaDB
(c) Operating System Types & Versions: Linux, Windows, Android,...
Linux
(d) Browser Types & Versions: Firefox, Chrome, Safari on iPhone,...
Brave and Chrome
(e) Ad Blockers, Browser Plugins, and/or Firewall Software?
Probably irrelevant here. (I've tried to turn them off, doesn't change anything).
7. On what kind of device is PhotoPrism installed?
This is especially important if you are reporting a performance, import, or indexing issue. You can skip this if you're reporting a problem you found in our public demo, or if it's a completely unrelated issue, such as incorrect page layout.
(a) Device / Processor Type: Raspberry Pi 4, Intel Core i7-3770, AMD Ryzen 7 3800X,...
Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz
(b) Physical Memory & Swap Space in GB
4gb and 4gb
(c) Storage Type: HDD, SSD, RAID, USB, Network Storage,...
SSD
(d) Anything else that might be helpful to know?
8. Do you use a Reverse Proxy, Firewall, VPN, or CDN?
Yes, I use SWAG which itself uses NGINX, but it's probably unrelated here as it used to work perfectly with that config.
I'll summarize what was found in the previous issue:
- There's a suspicion that this issue may arise when photoprism thinks there are different faces, assigned to the same person
- Make a "faces reset" works... But in the case of reporter of the previous issue it came back so not really a viable option
- It was asked if it could come from either running multiple instances or directly modifying database content. It's not the case for neither of these for me
- The original issue was closed because nobody shared their database, we've now send 2 of them for debugging
Let me start by saying this is a new issue that'll summarize a closed, but still happening issue. I'm creating this new issue based on @lastzero 's comment.
1. What is not working as documented?
For faces that were not added automatically, tagging people manually is slow to extremely slow. With some photos or persons (unsure), it takes a few seconds only (rare) but once that issue happens, most of the time it takes in my case between 1 and 2 minutes to tag 1 person. I've decided recently to move all my photos to photoprism so I've got quite a lot already, and quite a lot more to come. I have more than a couple hundreds pictures with unrecognized faces waiting to be tagged, but I'm not able to wait 1 to 2 mn for each, it'd be unmanageable.
It's documented as a known issue. I have tried the command
docker compose exec photoprism photoprism faces audit --fixbut it didn't help fixing the issue.2. How can we reproduce it?
I have no idea how exactly to reproduce this, but both @pjft and myself have shared parts of our database by email directly to help debug it. See pjft comment and mine. Best case scenario it's enough to debug, if not I'm more than happy to provide more info.
3. What behavior do you expect?
When a face is detected but unknown, it shouldn't take more than a few seconds to add it manually.
4. What could be the cause of your problem?
Really unsure, sorry.
5. Can you provide us with example files for testing, error logs, or screenshots?
As stated above, this has been done by email as it includes personal data.
6. Which software versions do you use?
(a) PhotoPrism Architecture & Build Number: AMD64, ARM64, ARMv7,...
Build 221118-e58fee0fb(b) Database Type & Version: MariaDB, MySQL, SQLite,...
MariaDB(c) Operating System Types & Versions: Linux, Windows, Android,...
Linux(d) Browser Types & Versions: Firefox, Chrome, Safari on iPhone,...
BraveandChrome(e) Ad Blockers, Browser Plugins, and/or Firewall Software?
Probably irrelevant here. (I've tried to turn them off, doesn't change anything).
7. On what kind of device is PhotoPrism installed?
This is especially important if you are reporting a performance, import, or indexing issue. You can skip this if you're reporting a problem you found in our public demo, or if it's a completely unrelated issue, such as incorrect page layout.
(a) Device / Processor Type: Raspberry Pi 4, Intel Core i7-3770, AMD Ryzen 7 3800X,...
Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz(b) Physical Memory & Swap Space in GB
4gb and 4gb
(c) Storage Type: HDD, SSD, RAID, USB, Network Storage,...
SSD
(d) Anything else that might be helpful to know?
8. Do you use a Reverse Proxy, Firewall, VPN, or CDN?
Yes, I use SWAG which itself uses NGINX, but it's probably unrelated here as it used to work perfectly with that config.
I'll summarize what was found in the previous issue: