-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent shared pictures from being recognized once by user #1111
Comments
Hello 👋 Thank you for taking the time to open this issue with recognize. I know it's frustrating when software I look forward to working with you on this issue |
What leads you to this conclusion? Recognize should not process shared files multiple times per sharee. If this is the case then this is a bug. Otherwise this may likely be a duplicate of #948 (please check it out ) |
Well, thank you for your fast answer. I'm struggling having the whole pics analyzed naturally, the "pending jobs" reported in the "Personnal Settings -> Recognize" tab are never triggered. This morning it was indicating 65000 files to be classified and 125000 files to be clustered. while true; do PHP_MEMORY_LIMIT=4096M php occ recognize:cluster-faces --batch-size=1000; done By doing so, I could see in the console that the job kept cycling through each users by 500 item each time, during 9 hours, until the end. Classification : Clustering : nothing left So I have just launched the "recognize:classify", it seems it scans the whole 200k files again, I don't really understand why the remaining job is not processing naturally, the log doesn't show any error. |
So, there's background jobs and there's the command line commands. You can run the cluster-faces command to work on unclustered faces, but you cannot run the classify command to work on queued photos for classification. The queue is tied to background jobs. So either you setup background jobs in nextcloud correctly and then wait for background jobs to finish processing queued files or you clear all queues and run the classify command to take care of everything for you. As you are doing it currently you are doing the same work multiple times. Generally, if the last background job ran not too long ago and the last classification was not too long ago, the system is working and you will simply have to wait for your 60000 photos to churn through it. Unless you don't have 60000 images at all, that would be a bug again. |
@marcelklehr I followed your advice and added CRON jobs to trigger classify. Face recognition: 0 Queued files, Last classification: 2 hours ago, Scheduled background jobs: 0, But there are still behaviours I don't understand. |
Photos in "Unassigned faces" are all after clustering. That means clustering couldn't assign them to a cluster. |
Describe the feature you'd like to request
My nextcloud instance is dedicated to my family. We share a lot of data.
There is already a fix for not analyzing several times the pictures from a group folder : #939
My concern is related but not the same : We have a "huge" shared photo library, 200k photos. This library is attached to a virtual "Sharing Account" user, that shares its data with all other people. I didn't use the "group folder" feature because the photo library is located in another drive, so I found this workaround in the nextcloud forum.
Now here is the problem : Recognize is classifying each photo 7 times : once per real user + once for the virtual "sharing account".
Not only this is counter productive, but I don't want (need) several users to use recognize, so this is a huge loss of time and energy.
Describe the solution you'd like
Currently the recognize feature is disabled for all users except me but the scan covers all users. As requested below, the scan should only target the enabled users or allow user targeting via a parameter.
#905
Describe alternatives you've considered
Another smart solution woud be to allow the sharing of the recognize data, so that all people from a nextcloud instance would benefit from a single tagging process, and a single manual curing process.
This feature request is described here : #948
The text was updated successfully, but these errors were encountered: