mirror of
https://github.com/photoprism/photoprism.git
synced 2026-03-02 22:57:18 -05:00
Faces: Error "Failed removing merged clusters for subject" seems to cause tagging of faces to become slow #1586
Labels
No labels
ai
android
api
auth
awesome
bug
bug
ci
cli
config
database
declined
deprecated
docker
docs 📚
documents
duplicate
easy
enhancement
enhancement
enhancement
epic
faces
feedback wanted
frontend
hacktoberfest
help wanted
idea
in-progress
incomplete
index
invalid
ios
labels
live
live
low-priority
macos
member-feature
metadata
mobile
nas
needs-analysis
no-coding-required
no-coding-required
observability
performance
places
please-test
plus-feature
priority
pro-feature
question
raspberry-pi
raw
released
released
released
research
resolved
security
sharing
tested
tests
third-party-issue
thumbnails
upgrade
upstream-issue
ux
vector
video
waiting
won't fix
won't fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/photoprism#1586
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chansearrington on GitHub (Oct 26, 2022).
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:
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 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)
@chansearrington commented on GitHub (Oct 26, 2022):
Another user had a similar experience here, and the same error.... but the thread is focused on the other error of "has ambiguous subject jr1e4i93ltym0svq" versus the failed removing failed cluster.
In both of my experiences of this happening, I have never had a "has ambiguous subject jr1e4i93ltym0svq" error.
Only "failed removing merged clusters for subject" errors.
The first time was ~10 different IDs.
This time it is only one ID causing the same performance impact.
@lastzero commented on GitHub (Oct 26, 2022):
Have you discovered the "photoprism faces audit" CLI command yet and the trace log mode? There's a big chance these can give you a clue as to what is wrong. It's absolutely true that failing to remove merged clusters would lead to this kind of behavior. We could be more aggressive here, but that could lead to data loss in rare cases, for example when the user provides inconsistent assignments that don't make sense.
@chansearrington commented on GitHub (Oct 26, 2022):
@lastzero was actually waiting for it to complete. Here's the audit log
@lastzero commented on GitHub (Oct 26, 2022):
See also: https://github.com/photoprism/photoprism/discussions/2022#discussioncomment-3977078
@lastzero commented on GitHub (Oct 27, 2022):
Could it be that these faces have been marked as "hidden" in the UI? A look at the code (note the arguments of the FacesByID function!) would explain why this warning is displayed further down, and also why they could not be matched or merging might fail:
It comes down to better understanding what you did and what behavior is expected. Perhaps we should still work with these hidden faces when the alternative is poor performance or other problems.
@lastzero commented on GitHub (Oct 29, 2022):
We look forward to an answer to the above question so we can find out what is causing this.
@QrchackOfficial commented on GitHub (Nov 10, 2022):
Tuning in from #1598, I just ran
photoprism audit --fixwith the following output:15 minutes later, I still see this in logs:
@lastzero commented on GitHub (Nov 10, 2022):
Alright, did you read my last comment? See question:
@lastzero commented on GitHub (Nov 10, 2022):
Also enable the debug or trace mode when you run the audit command, as it displays additional logs that can be helpful.
Edit: In every event, there should never be "88 clusters" to merge every 15 minutes. One more thing that would be good to know for debugging is what database (version) you use and if you know how we might reproduce this (what did you do?).
@QrchackOfficial commented on GitHub (Nov 10, 2022):
Don't recall specifically hiding or seeing a hide button, though anything is possible as I've been fumbling my way through the software just clicking things and seeing what happens. That said I can say for sure that I:
Might have also jumped around between edit photo view and gallery/thumbnail view while doing this
@QrchackOfficial commented on GitHub (Nov 10, 2022):
How do I debug/trace with a docker-compose based deploy?
Agreed, and it is exactly 88 clusters, every 15 minutes and maxes disk I/O plus takes the exact same ~12 seconds - every time.
The docker-compose stack runs
mariadb:10.9(as copied from the install instructions on the website) withphotoprism/photoprism:latestand I'm sure all images have been recently pulled as the stack haswatchtowerfor auto-updates as well.@lastzero commented on GitHub (Nov 10, 2022):
Using different names for the same face ("typos") could cause conflict resolution issues, although we improved that a lot earlier this year.
You can enable trace mode and run commands like this:
photoprism --trace command [subcommand] [--subcommand-flag] [argument]@lastzero commented on GitHub (Nov 10, 2022):
See also the built-in command help: https://docs.photoprism.app/getting-started/docker-compose/#command-line-interface
@QrchackOfficial commented on GitHub (Nov 10, 2022):
You're losing bropoints for the management script ignoring output redirection to a file, but fine - here's trace:
Let me know if this helps anything, or if there's anything else I can run to help. For reference, this is running on Proxmox, in a LXC with Alpine Linux installed, that has Docker installed in it, and PhotoPrism runs in that Docker environment as a docker-compose stack.
@lastzero commented on GitHub (Nov 10, 2022):
There's also the faces optimize and index subcommands you might want to try. Use the command help please, these do have descriptions including descriptions for different flags you can use.
What are "bropoints" and why do I lose them? I'm on my phone and preparing dinner right now 😋
@QrchackOfficial commented on GitHub (Nov 10, 2022):
Hah, sure will have a look around. Bropoints as in buddy/friend points, not being able to redirect to a file and copypasta straight to you (vs piecing together one screen of terminal at a time in a text editor) makes me a sad panda
@QrchackOfficial commented on GitHub (Nov 10, 2022):
Enjoy your meal tho! No peeking at github randoms 👀
@lastzero commented on GitHub (Nov 10, 2022):
That's intentional, because otherwise you'll have debug logs in your SQL dump, or CSV export. This would make all our other users sad, and they wouldn't notice until they need the backup.
@QrchackOfficial commented on GitHub (Nov 10, 2022):
Database migrations all say OK. I'm getting 8 faces matched to the same person in stats.
Does this mean the management script outputs SQL dumps / CSV to stdout instead of taking an output file to write to? Sounds a bit crazy...
@lastzero commented on GitHub (Nov 10, 2022):
Try
photoprism --trace faces optimize. The backup command will output a SQL dump, for example. Since you normally use docker exec, stdout is used by default, otherwise you will have to use a temporary file in a mounted directory, which I would not recommend unless you hate yourself.@lastzero commented on GitHub (Nov 10, 2022):
If you want to know details about the backup command, please check the command help :)
@lastzero commented on GitHub (Nov 10, 2022):
Also, if you're nice, I might eventually show you how to pipe the logs to a file.
@QrchackOfficial commented on GitHub (Nov 10, 2022):
Hmm. Full on
faces indexalso failed:@lastzero commented on GitHub (Nov 10, 2022):
OK, so we know as much as before. Thanks for trying though! 👍
@QrchackOfficial commented on GitHub (Nov 10, 2022):
I tried the
faces optimizethough and it seems to say more:@QrchackOfficial commented on GitHub (Nov 10, 2022):
Seems like it's failing on 2 people specifically, and I presume this means they have what PhotoPrism thinks are multiple different faces, assigned to the same person. This would be for things like with/without sunglasses, in poor lighting etc.
@lastzero commented on GitHub (Nov 10, 2022):
Note you can use the "photoprism faces reset" command for a clean start without these warnings. Of course not an option if you already put a lot of time in labeling faces.
@lastzero commented on GitHub (Nov 10, 2022):
Multiple faces for the same person are OK. The same face belonging to different people is what MAY cause conflicts, which could not always be resolved as they should. That makes it difficult to reproduce as most users never have such issues.
@ER-EPR commented on GitHub (Nov 12, 2022):
I have the same issue, which has tortured me for a month. I have labeled hundreds of photos already, I can't just reset all and start again. Can you display the file and the person that is causing the problem instead of a random serial number. And provide a command to reset the label on that file or person.
@ER-EPR commented on GitHub (Nov 12, 2022):
I have used every index/face related command, including ones from above comments, but the log keeps showing:
@ER-EPR commented on GitHub (Nov 12, 2022):
docker exec -it photoprism photoprism faces audit -f
shows:
@lastzero commented on GitHub (Nov 12, 2022):
If you know a little SQL you can check the subjects, faces and markers tables for the related records. As I said earlier, there's probably something inconsistent or missing. Like when you have hidden face clusters that have already been matched to a subject. Or used different names for the same face cluster. I can just guess, which takes months without your help.
@lastzero commented on GitHub (Nov 12, 2022):
Also make sure to run the commands with --trace or --debug as that may show more information if needed.
@ER-EPR commented on GitHub (Nov 12, 2022):
I know the basics, but I am not a SQL expert. Most of all, I don't know what to look for. Would you please provide a query / an example SQL command for me?
@lastzero commented on GitHub (Nov 12, 2022):
You would find the names for the subject UIDs, so you can look those people in the UI and fix issues if needed. The UID is in the subject_uid colum, and the name in the subject_name column of the subjects table. "Select * from subjects" would be the query.
@ER-EPR commented on GitHub (Nov 12, 2022):
OK, I have found those names. But I can't see anything unusual. What should I do next？
@ER-EPR commented on GitHub (Nov 12, 2022):
I maybe found the solution. I found 3 out-of-focus image of the third person, and un-label them. And init face update, the third subject warning disappeared. I try the same thing with the first two, but it did not work.
Where can I look up these IDs
SDFJCXAPT2YDYRDNKPX4RKWGK245NYGV
LQTVVRLFE5BXPAFSJCLR7W4Z5IMGOHJT
LUFXBOJB7VBJJVVFJA7THXD5YN2LGT7S
Are they image file IDs?
@lastzero commented on GitHub (Nov 12, 2022):
faces table and markers table. These are face IDs.
@ER-EPR commented on GitHub (Nov 13, 2022):
from makers and files table, I found the file names. I untag all those files, the second person's warning disappear. But still the first warning stays.
Can you add a new web UI for conflict resolve, to review those image and untag them all? At least you could integrate those info in the debug log in the future.
Now the face update log still show warnnings for the two people. I looked up the faces in the database, and found out they don't even have a marker. Or maybe it's an empty/NULL marker? Is it possible this is the problem?
How can I clear those markers/tags without a marker/tag…………？It's really weird. I mean the marker_name column is empty.
@ER-EPR commented on GitHub (Nov 13, 2022):
I guess they are automatically tagged markers, I untag faces belong to LQTVVRLFE5BXPAFSJCLR7W4Z5IMGOHJT and WOOJCFSIGUGZAZLRD5L4TH7VCOPSVLMH (which have less number of images then 6UDBI4YVRK6WV7U7XUSVRP6JIIP3FH7G ). And the warning disappears. Would you add this kind of function? Based on how many images in each face_id, untag the small groups of images and try to resolve the conflict.
@lastzero commented on GitHub (Nov 13, 2022):
Thanks for your analysis! We will try to improve the auto resolution based on your findings. Note, however, that this will take time. We also welcome pull requests with specific improvements.
@ER-EPR commented on GitHub (Nov 13, 2022):
Thanks for your help. The lag when tagging people is gone now. But the audit log shows some problems, and it probably causes the regular background job acting weird. It consumes 100% of 1 CPU core, but my CPU fan sounds crazy because of it.
How can I fix
and
I'm new to github, do I have to start a new issue for this?
@lastzero commented on GitHub (Nov 14, 2022):
This might be related to the changes you performed and comes closer to the original issue. Maybe it also was there from the start. Resolving this is possible, but you either need to wait for an update from us (will take a little) or you also figure out how to fix it manually.
@ER-EPR commented on GitHub (Nov 14, 2022):
It is there from the start before I do anything. It is a separate problem. The lag when adding tags is gone now.
I need some insight, into what I should and not do. Can I safely delete those markers from the database just by SQL? Or Do I have to edit other files as well? I see the debug info is all about makers having invalid data.
But it is possible that these warnings are the true reason that the original issue cannot be auto-solved. Anyway, I need to be point to a direction.
@lastzero commented on GitHub (Nov 14, 2022):
Deleting those markers might work. You could also try to empty the face id value of those markers instead of deleting the complete row. Please create a backup before you do that, so you can revert any changes if needed.
@ER-EPR commented on GitHub (Nov 14, 2022):
I clear the face_id using
update markers set face_id = '' where marker_uid='mrksd3s29b4r1vbr' or marker_uid='mrjbjes3jl46cb33' or marker_uid='mrksd3z3ms9m8i7i' or marker_uid='mrksd 3r37nang8kw' or marker_uid='mrksd4n11316s5za' or marker_uid='mrksd3utqs80hw6o' or marker_uid='mrksd3w3s15qe9rb' or marker_uid='mrksd3s29b4r1vbr' or marker_uid='mrksd3v2ju7ueb0 ' or marker_uid='mrksdb62n47zalcp' or marker_uid='mrksdbd1gg8wrt9b' or marker_uid='mrksdbs2sxauv62b' or marker_uid='mrksah91r7p0fw1c' or marker_uid='mrksdbr3hdd4y5zr' or marke _uid='mrksdba1osp9qrev' or marker_uid='mrksdbaydxgwrne0' or marker_uid='mrksdbb3epk4eox3' or marker_uid='mrksdbcr9jv87bpr' or marker_uid='mrksd462pvt4rxvc' or marker_uid='mrks 4l2jv75kwqv';the warnings are gone but the face update and face audit process still running too long(5 minutes with one cpu core at 100%, I set worker to 8 actually, but only one running). The face optimize command only takes 548ms though. I have more than 15000 files, most jpeg, less than 100 of them are videos. Is it normal? It seems thefaces: found no ambiguous subjectstakes 5min to complete from the time stamp in the logs. Anything else I can do to figure out what process/file is causing the problem?the face update log:
and the audit log:
@lastzero commented on GitHub (Nov 14, 2022):
Yeah, the audit command always takes a while to complete. This is to be expected.
@ER-EPR commented on GitHub (Nov 14, 2022):
But it wasn't this noisy last month. Considering there is nothing to audit, nothing changed, I think there probably something wrong with the
faces: found no ambiguous subjectsprocess. How can I find more info about this. Now I have to set the background job to 24h to prevent the noisy sound it produces.@lastzero commented on GitHub (Nov 14, 2022):
The logs look good. The message "faces: found no ambiguous subjects" means that everything seems to be fine. We run a lot of servers for our own use and have never observed any performance problems (unless you are dealing with millions of files) and the CPU fans are also not audible unless you do a full rescan.
A good way to avoid fan noise would be to buy a suitable cooler that is not so noisy or change the BIOS setting.
It is not possible to NOT use the CPU for an application like this. We can improve it if we have enough time and money, but we can't avoid it completely. Disabling the background worker or just running it every day can cause problems, as discussed in the endless comments in other Issues and GitHub Discussions. My recommendation is not to do this.
@ER-EPR commented on GitHub (Nov 14, 2022):
#2022
#1618
#1872
#2176
I searched all related problems, and I come to a conclusion. The two problems we discussed in this post are all because of lots of manually tagged photos. The second problem '1 CPU core at 100%' for several minutes is mentioned by other users several times, and all of them have tag the photos a a lot. It is mainly related to the number of the tags. The first problem 'tag person delay' I guess is because of tagging too many photos between two background task, especially for the same person. And maybe even during the background task make it worse. All those tag broke the algorithm somehow.
I have a possible solution for those two problems. Just delete repeated tags that already belongs to a merged cluster. I want to test the theory, but my SQL knowledge seems not enough. How can I retain only one manual tag for a face cluster while delete all else using SQL?
@lastzero commented on GitHub (Nov 14, 2022):
The reason the worker currently runs independent of actual changes in the main instance is that some users directly change database contents or run additional instances, for example for indexing. That's a problem that CAN be solved, but it takes time. If we just ignore this fact and don't consistently run the worker, it will lead to bug reports and support requests we need to handle. I didn't code a single line today because I was just busy pointing out technical details and explaining things. We thought about the implementation a lot and, like I said before already, will improve it as our time and budget allows.
@lastzero commented on GitHub (Nov 14, 2022):
As for your question about the exact SQL statements, I'm smart but not a computer that can just print out validated statements that work for you. I'll think about it when my time permits, but that's not possible if I'm constantly answering questions, since I can only focus on one thing at a time.
@lastzero commented on GitHub (Nov 14, 2022):
In fact, one possible cause of the problems you and other users describe is that they are running multiple instances or directly modify database contents, as this MAY result in inconsistent faces, markers, and subjects. If you would like to help us resolve this issue, please let us know if this might apply to you. Thank you very much!
@lastzero commented on GitHub (Nov 14, 2022):
PS: As you found out, it is also possible that manually tagged faces play a role. However, these should be represented by a cluster (instead of many individual faces that need to be compared). This is exactly what the background worker does. Hence my advice (see above) not to disable it, or run it less frequently. That would be exactly what causes the problems in the first place.
@QrchackOfficial commented on GitHub (Nov 14, 2022):
Wow, quite the traffic in here recently. I'll add that in my specific case there's just one instance running, but the manual tagging was most certainly done fast and to avoid waiting for the UI blocking progress bar I would close out of the tab and tag in another. Meaning there's a decent chance that there were several tags being applied while the database was updating in the background.
@lastzero commented on GitHub (Nov 14, 2022):
Another known issue is that children and Asian faces can't be compared properly because our model doesn't work well for them due to lack of training data (i.e., images that could be used - note that parents don't usually give away pictures of their children). Since we keep explaining this, maybe it would be best if I sit down now and add this to our docs on the "Known Issues" page so I can finally get back to coding something instead of explaining things. Appreciate your efforts!
@ER-EPR commented on GitHub (Nov 14, 2022):
I'm sure I only run one instance, in docker. And I only learned to modify database today with your guidance. And those modifications work well. The problems were there for several weeks. And it's getting better after today's modification. The only problem left now is as #1872 describes. The comparison process of faces may take too much time, especially when nothing has changed since the last index. As you said, it can be done, just don't do face compare when no new changes in the index are enough.
I know I may ask a lot, but I really want to see this project works well. I put photos of my life in this photoprism server. I'll try to write some python script to clear the database to see whether it will improve the background job.
I constantly check the face update or face optimize or face audit output, no new merges after the initial run. So I don't think it will happen afterward when no input is changed. Unless your algorism uses a random start point for machine learning.
To conclude, I think stopping face recognition background job when no new index or tags is the easy solution. And will satisfy most people. Other background job works fine, just disable this one
faces: found no ambiguous subjectswhen no index change will reduce the time consumption dramatically.@lastzero commented on GitHub (Nov 14, 2022):
@ER-EPR Based on your profile picture, I think the user experience would be much better for you if our model worked better with Asian faces. Except for the noise your fan might make. We want to solve these and many other problems, but it takes time and money to build a team of specialists.
Be aware that I have only studied Physics and read research papers, I am not a full time face recognition specialist who does nothing else in his life. We certainly can't hire someone like that with our current resources. So our next goal is to improve funding instead of introducing more and more workarounds and tiny improvements, like experimenting with the worker schedule. That ties up resources we need for the bigger goals.
@lastzero commented on GitHub (Nov 14, 2022):
Using multiple tabs instead of waiting would almost certainly cause the behavior you observed. Thanks for letting us know! We should include that as a note in our docs.
@ER-EPR commented on GitHub (Nov 14, 2022):
@QrchackOfficial The merge fail can be cured by untagging small clusters of one subject as I did in the above posts using MySQL. You can search in the markers table for a subj_uid, and see the face_id listed in the warning, and clear the tags of the small groups and let them merge with the big group.(don't untag the big group) But remember to backup your database first. It's a dangerous act.
@lastzero commented on GitHub (Nov 14, 2022):
You are welcome to privately provide us with a SQL dump of the subjects, faces, and markers tables for debugging. This would save us hours of reverse-engineering your (potential) database content based on the GitHub issue comments, which could eventually lead us to solutions that don't work for you because we got it wrong. Thank you very much!
@lastzero commented on GitHub (Nov 14, 2022):
The documentation has been updated for you:
Legacy Hardware
It is a known issue that the user interface and backend operations, especially face recognition, can be slow or even crash on older hardware due to a lack of resources.
Like most applications, PhotoPrism has certain requirements and our development process does not include testing on unsupported or unusual hardware.
Asian Faces and Children
It is a known issue that children and Asian-looking faces cannot be recognized reliably. Detection without automatic recognition should not be affected by that.
This is because the model we use was trained with North American images, which unfortunately do not include many Asians. The absence of children in the training data comes from the fact that parents do not usually share such images under a public license (and may not have the right to do so).
We will continue to improve our models over time as our resources allow.
Background Worker
Face recognition was developed and tested under the assumption that the background worker runs every 15 minutes, unless the backend is busy with other tasks like indexing. It has not been tested with much longer intervals and is not designed for that.
PhotoPrism's background worker groups new faces by similarity, compares faces with clusters, and optimizes existing clusters as needed. Without these routine tasks, the number of faces to be processed becomes too large. The first and next time the worker runs, it can then cause a heavy server load until all the faces, face clusters, and related pictures have been updated. The longer you wait, the more CPU is required and the longer it takes.
An important reason for the worker to run independently of actual changes in the main instance is that some users change the database content directly or run additional instances, for example for indexing. It is a problem that can be solved, but it takes time. If we were to ignore this and don't run the worker at all times, it could lead to many additional support requests, further reducing the amount of time we can spend on development.
The handling of changes in multiple instances will be improved over time so that the worker can be run less frequently in future releases.
Removing Merged Clusters Fails
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:
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 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!
@lastzero commented on GitHub (Nov 17, 2022):
I am closing this issue as we have not received any further feedback from the original reporter and there are now too many comments, making it difficult for anyone who has not participated in the discussion to understand. Everything important is now covered in the Known Issues. If someone affected provides us with a dump of the database tables, we can fix the problem - otherwise it requires too much time and luck:
👉 https://docs.photoprism.app/known-issues/#removing-merged-clusters-fails
@ER-EPR commented on GitHub (Nov 18, 2022):
I have sent you two emails containing download links for the mysql dump for the three tables. The first link may have expired, please use the second one.
@pjft commented on GitHub (Jan 2, 2023):
@lastzero happy new year. I'm happy to provide you with the database files for debugging, but I'd probably need some guidance in getting them. I am running into the exact same issues.
Single instance, on docker. I did not manually edit the database.
Happy to help in any way here.
@maxime1992 commented on GitHub (Jan 14, 2023):
Same over here. It takes sometimes about a minute or maybe 2 to add someone, when it works. It sometimes says it's "busy" or just "Have you lost network" (can't remember exactly but anyway, like something went wrong).
If there's a step by step guide I'm willing to provide some data as well as this feature is fantastic but pretty much unusable at all for me at the moment as I've started to use photoprism recently and I'm massively adding pictures, and have a lot to tag as well.
PS: I've tried to run the commands and work arounds from that issue but none of them worked for me.
@pjft commented on GitHub (Jan 14, 2023):
I reset my faces, even though I already had a meaningful amount of faces tagged - no more clusters to tag, from 780 original clusters, as well as individual faces that needed to be fixed in clusters where they had been mis-tagged.
I am now first taking care of organizing my full library, with albums and whatnot, and then I'll do a backup and try to go after the face tagging.
The commands didn't really help.
@lastzero commented on GitHub (Jan 14, 2023):
Unfortunately, even after 5 years, I'm still the only full-time developer. I'll took into it as soon as possible.
@pjft commented on GitHub (Jan 14, 2023):
Hi @lastzero . Never meant this to be taken in any way other than just updating here.
My last post still stands: happy to share my "broken" database if it helps, though I think it's still around 1GB.
Thanks for building Photoprism. It's a fantastic app. I know there are other priorities on the table.
Just let us know how we can help.
@lastzero commented on GitHub (Jan 14, 2023):
The dump might be really helpful. However, the subjects, markers and faces tables should be enough for debugging. That will reduce the size so you can send a link or attach it as a zip to an email. Thank you! ❤️
@pjft commented on GitHub (Jan 14, 2023):
Just sent it to the hello@ email address, with a link to download the database.
Hope it helps - let me know if you don't get it for some reason.
Have a great weekend!
@maxime1992 commented on GitHub (Jan 15, 2023):
Hello @lastzero 👋
Same as what @pjft said, we very much appreciate your time on the project and we know there are some priorities. We're just here to help so that if you feel looking back into this issue at one point, you've got the data you need. Sorry if my previous message came across the wrong way!
I just sent you on the hello address a dump of the 3 tables you asked for. Hope it helps 🤞 !
Based on this comment and the fact that you shall now have the data you need to debug, would you consider reopening the issue maybe?
Have a good weekend
@lastzero commented on GitHub (Jan 15, 2023):
Given the long list of comments, it seems best to open a new issue. The new issue should contain a summary of everything that seems important to get to a solution and, for example, has been mentioned here, but also in GitHub Discussions. Feel free to move ahead with this, as I'm drowning in work right now and don't know when I'll get to it. Thank you very much, also for the kind words!