When returning faces to unknown Scrolling down leaves empty spaces and invalid page

[scepterus]

🐛 Bug Report

• [ ] 📁 I've Included a ZIP file containing my librephotos log files
• [X] ❌ I have looked for similar issues (including closed ones)
• [ ] 🎬 (If applicable) I've provided pictures or links to videos that clearly demonstrate the issue

📝 Description of issue:

When I go to the face tab and in the inferred tab change the assignment of more than X number of pictures, when scrolling down I get empty spaces and a pop-up that says Invalid Page until I refresh.

🔁 How can we reproduce it:

Go to faces page, do more than a few rows of changes, and continue scrolling. Sometimes if the faces are not grouped together it happens more often, so if it's not the whole row.

Please provide additional information:

• 💻 Operating system: TrueNAS
• ⚙ Architecture (x86 or ARM): x86
• 🔢 Librephotos version: Latest Stable
• 📸 Librephotos installation method (Docker, Kubernetes, .deb, etc.): Docker
  • 🐋 If Docker or Kubernets, provide docker-compose image tag:
• 📁 How is you picture library mounted (Local file system (Type), NFS, SMB, etc.): Direct Mount
• ☁ If you are virtualizing librephotos, Virtualization platform (Proxmox, Xen, HyperV, etc.):

[derneuere]

Looks like the counting for unknown faces was just broken in general. Fixed a push and that will be in the next release :)

[scepterus]

Still happens, it happens less, but still does. I noticed this when a returned a lot, like 40 pictures, to unknown that this happened.

[scepterus]

Just to note, this was before the frontend container update. I don't have enough photos in inferred after that update.

[scepterus]

Still present in the latest version.

[nowheretobefound]

Is this relevant ? librephotos-proxy-1 | 2023/11/19 13:17:49 [info] 36#36: *1834 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 192.168.1.169, server: , request: "GET /media/faces/8603e22951fed35642ae11bf0fa31a633_3.jpg HTTP/1.1", upstream: "http://192.168.80.3:8001/media/faces/8603e22951fed35642ae11bf0fa31a633_3.jpg", host: "cloud:3000", referrer: "http://cloud:3000/faces"

[nowheretobefound]

Not to nag, but this is actually making the faces tagging process unusable.

[sefininio]

I get this too. I am having a strange issue with tagging faces. When I navigate to the Faces->Inferred tab, I see the faces to infer. I tag a few faces and then I get an error message and looking at the dev tools I see that person 491 page 2 is failing. But the strange thing is that just before it - the request was successful. Only after tagging and only for this person 491 page 2 I get the error. This in itself not a problem, but the result is that all faces vanish and I cannot tag any more, only a browser refresh brings them back, until the next tag...

This effectively makes tagging a nightmare 😦

Console error log:

fetchBaseQuery.ts:40 
        
        
       GET http://192.168.1.4:3000/api/faces/?person=491&page=2&inferred=true&order_by=confidence 404 (Not Found)
Jg @ fetchBaseQuery.ts:40
(anonymous) @ fetchBaseQuery.ts:281
(anonymous) @ apiState.ts:34
(anonymous) @ apiState.ts:34
i @ apiState.ts:34
Promise.then (async)
s @ apiState.ts:34
(anonymous) @ apiState.ts:34
Gg @ apiState.ts:34
(anonymous) @ fetchBaseQuery.ts:215
(anonymous) @ api.ts:86
d @ regeneratorRuntime.js:44
(anonymous) @ regeneratorRuntime.js:125
(anonymous) @ regeneratorRuntime.js:69
r @ asyncToGenerator.js:3
s @ asyncToGenerator.js:22
(anonymous) @ asyncToGenerator.js:27
(anonymous) @ asyncToGenerator.js:19
(anonymous) @ api.ts:81
(anonymous) @ buildThunks.ts:390
(anonymous) @ apiState.ts:34
(anonymous) @ apiState.ts:34
(anonymous) @ apiState.ts:34
Gg @ apiState.ts:34
u @ buildThunks.ts:363
(anonymous) @ createAsyncThunk.ts:637
(anonymous) @ index.js:32
(anonymous) @ index.js:32
(anonymous) @ index.js:32
Jv @ index.js:32
(anonymous) @ createAsyncThunk.ts:599
Object.assign.pending @ createAsyncThunk.ts:599
(anonymous) @ index.js:16
dispatch @ redux.js:691
(anonymous) @ buildInitiate.ts:354
(anonymous) @ index.js:16
(anonymous) @ FaceDashboard.tsx:100
(anonymous) @ FaceDashboard.tsx:95
ou @ react-dom.production.min.js:244
kl @ react-dom.production.min.js:286
(anonymous) @ react-dom.production.min.js:283
xl @ react-dom.production.min.js:281
ll @ react-dom.production.min.js:273
Ho @ react-dom.production.min.js:127
(anonymous) @ react-dom.production.min.js:267

See screen capture here: https://www.kapwing.com/w/fx_AqJiibc I tried re-scanning the library, that didnt help

I checked the DB - person 491 is a valid person (not an unknown cluster), so not sure how to pinpoint the face that causes issues...

Logs from the logs folder: logs.zip

I understand this is hard to reproduce - so I am happy to try and debug this locally, if you can provide instructions on where to look

[sefininio]

Even when there are no faces inferred left to tag, the error still appears

[sefininio]

Actually, I think it is not the same issue. The issue I am facing is related to a specific person request that returns 200 for ?inferred=false and 404 for ?inferred=true, even when there are no inferred faces

[sefininio]

@nowheretobefound -can you confirm you get the same errors on the devtools console?

[nowheretobefound]

Dont get the same errors, but others, this is after tagging a face, all faces disappear, sometimes they come back cak toggling the sort order (date/confidence), or scrolling a long way to a different part of the page and other faces stats to popup, which of course disappears again if you tag something.

[sefininio]

@derneuere Maybe some data corruption or dirty state causes the request to be made when it should not?

[derneuere]

@sefininio I found one potential issue, that would cause an invalid page. I pushed a fix. Can you check if it improved it?

[sefininio]

@derneuere Sure, happy to. Do I need to use the dev env to verify? Or is it already merged to master and released a new version of the container?

[derneuere]

For now only on dev or in the next release in January :)

[sefininio]

Allright, so since I'm using docker, just replace latest tag with dev?

[derneuere]

Yes exactly :)

[sefininio]

@derneuere Preliminary tests on empty enferred collection - no error! Yay! I'm gonna start a new image scan and check again when there are inferred faces and report back.

Looks promising! 🤞

[sefininio]

Well, no errors any more. However - I now get almost no faces inferred. Out of a 9175 new pictures scan, only 64 inferred - so something broke, not sure if it is the fix or the dev server 🤷

The settings I am using for clustering etc didn't change, and worked well before the move from latest to dev. I'll try running latest backend+proxy and dev frontend next.

[sefininio]

@derneuere Using version 2024w01 - this issue is still happening...

[derneuere]

This sounds like a new issue. Can you confirm, that the invalid page error is gone?

[sefininio]

Actually it happened only once and didnt happen again so far.

[nowheretobefound]

No more invalid page, the faces are still blank however.

[derneuere]

Pushed another small fix, would be great if somebody could confirm, if it works better now.

[nowheretobefound]

Nice, seems to work much better now, still sometimes you need to scroll up or down or toggle sorting Confidence/Date to make some faces to show up after tagging a face in Inferred tab

[scepterus]

Still happens today with the latest versions of everything, on the GPU branch.

[sonntam]

Happens to me as well on 2024w23 running with the docker compose file on a Synology DS923+