-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
old people thumbnails broken after swiching to webp #9944
Comments
Hi, thanks for the report! Person thumbnails are currently always in JPEG format. We can change this to respect the thumbnail format. However, this isn't problematic in itself and doesn't explain why the thumbnails didn't get generated after running on all assets. Can you set the log level to verbose, run thumbnail generation on all assets and immediately pause the queue? After it finishes queueing, can you check if there are any errors in the microservices container? If there are no errors, then unpause it and just let it run. The person thumbnails will be generated last, at which point we can look at the logs relating to them. |
There are indeed some ffprobe-errors. Here is the log-output when pausing right after starting and letting all entries queue:
I will now let it run and will update you when the logs are available |
The Job is still running (80k thumbnails to go) but there are already errors in the logs that might be of intereset. A lot of these appeared:
I will provide the full logs when the job has finished |
Oh, that's really helpful actually. Could you run this command and share the output?
|
I will do that first thing tomorrow morning after making the first coffee :) |
Interesting. After this run about 50% of faces reappeared. Will run the query when i'm at my desk in about 1:30h |
@mertalev Here's the query result:
I checked, the file in "originalPath" and "previewPath" do exist. The jpeg in "personThumbnailPath" does not exist. |
Interesting! I was expecting either a video or an image with dimensions that don't scale cleanly, but this asset doesn't seem like an edge case. Unless it's maybe stemming from the face bounding box? I'll take a closer look at this tomorrow. |
@mertalev if it helps, this is the original image you told me to query (asset |
This is probably fixed with #10382. At the very least, I've tried changing the preview for this image to different resolutions and regenerating the person thumbnail and it's worked for every combination. Tentatively closing, but feel free to re-open if you still have the issue. |
This sounds like that could be the cause of my issues here. |
@mertalev sadly, even after updating to 1.7.2 and rerunning the generation of all thumbnails, still about half of the face previews are missing (just like before the update) :( Could you please re-open the issue? I don't have the rights to do so. |
Are the errors in the logs the same as before? |
Thanks for reopening! I had no time to check the logs yet. I will do so soon |
@mertalev I checked the logs now. The Error seems to be the same.
When seaerching for one of the file-ids in the whole log, i only see one other Error that happened while generating the thumbnails:
|
Thanks for the logs! Hmm, the |
any news on this? I am not sure if it is related, but it is the issue I found first when I was investigating the problem I just had. I am running Immich in kubernetes container (not helm-based from repo), all paths are correct, yet I don't understand edit: I have also noticed that image previews are broken randomly. I got enough of space and there are no errors in logs, it just shows the broken preview thumbnail and when I open some image I get that "broken thumbnail" image in full preview. |
@luckyycode This issue is about an edge case when cropping person thumbnails, not relevant to your issue. You can try generating thumbnails for all assets through the job panel. It will either fix your issue, or you'll get error logs describing why the thumbnail or preview couldn't be generated. |
Hi, I had the same issue even after switching back to JPEG. The issue lied on the |
@freitzzz i had no orphaned images or containers around, but tried |
I'm currently investigating this. this.logger.log(
`getting crop ${[
dims.new.width, dims.old.width,
dims.new.height, dims.old.height,
widthScale, heightScale,
x2, x1, y2, y1,
halfWidth, halfHeight,
middleX, middleY,
targetHalfSize,
newHalfSize,
middleX - newHalfSize,
middleY - newHalfSize,
newHalfSize * 2,
].join(', ')}`,
); immich hasn't finished regenerating all thumbnails yet, but i do have logs of failed person thumbnails. Here is one example:
According to this
Next step would be to find out where |
Turns out i have a lot of entries in select count(*) from asset_faces where "imageWidth" = 0;
16125
select count(*) from asset_faces where "imageWidth" <> 0;
71129 From the code i've seen i strongly assume that that's the reason why getCrop fails, which is the reason i have missing people-faces @mertalev i'm not sure what the best way to continue is. I see a couple of possibilities:
Would be interesting to know how these entries ended up there. What do you think? |
That's pretty strange. There's not much we can do with a bounding box if we don't know the dimensions of the image it's associated with. I'm working on a way to re-run face detection and merge the results. Maybe I can make it update the image dimensions if they're different. If you know what the actual preview dimensions are, you can update the DB yourself. Or if you at least know that images taken with X camera end up with certain preview dimensions, you can join on the exif table and only update those face entries. |
@mertalev Thank's for the quick reply! As you mention the bounding-box values, they are also 0 for these entries: Am i correct to assume that these entries are therefore damaged beyond repair? Updating the values by hand sound tedious and error-prone. i know the |
You can just re-run face detection on all assets and it will clean everything up. |
That worked :) I have to re-assign names to faces, but that's fine (for me). immich warned me that that would happen if i confirm to re-run face-detection on all assets. But there are now no more missing face thumbnails :) |
I believe this issue has been resolved now. We did find a case with changing webp to jpeg and running the thumbnail job could overwrite thumbnails. |
The bug
When 1.102.0 released, which introduced webp support for thumbnails and previews, i switched to webp.
I had issues with thumbnails and read #8981.
I deleted all jpeg files and reran about every job immich provides.
Most things work fine, but the thumbnails for people are not showing.
Logs show, that immich tries to load
.jpeg
files like this.If i look into that folder, a file with than name exists, but it has the (correct)
.webp
ending.Interestingly enough, thumbnails of new people from photos from two weeks ago and yesterday do show up correctly.
When i look at the person-table, there is no entry with
.webp
-path (althouth there are thousands with.jpeg
-path)In the code, i found a
handlePersonMigration
, which callsmovePersonFile
which in turn usesgetPersonThumbnailPath
as target-path.getPersonThumbnailPath has the
.jpeg
-ending hardcoded. Could that be an issue?How do i tell immich to update the paths of the thumbnails for the persons to webp?
The OS that Immich Server is running on
Ubuntu 22.04
Version of Immich Server
v1.105.1
Version of Immich Mobile App
v1.105.1
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Relevant log output
Additional information
.jpeg
ingetPersonThumbnailPath
be the cause?The text was updated successfully, but these errors were encountered: