Closed maltokyo closed 1 month ago
Re-run the RECOGNIZE FACES
job before updating immich should fix it
Re-run the
RECOGNIZE FACES
job before updating immich should fix it
Thanks, but now the container won't start at all, so no way to rerun it.. (?)
Just downgrade to v1.89
ok, downgraded. Do I have to rerun for ALL faces? I have nearly 1million faces, it will take days.. wondering if you think run for "missing" would be enough?
Well, if you can't upgrade it's because the migration script for v1.90 fails. I couldn't reproduce this issue so I suspect there's an error in one of your tables and the migration script miss your edge case. Unless you can see the error in the migration script / in your tables, I don't think there's a easy solution. You will have to wipe everything with "all", "missing" is not enough
tried with just "missing", as you said it did not fix it. That is a pain. All I did was upgrade, strange that it now has a DB error. Will try all faces and report back in a few days ;(
Oh no...
I have spent hours tagging people. I don't want to lose this work... is anyone else able to help with a way to fix the db error? Will wait a few days and see.
Well, what you can do is to set faceAssetId
to null with UPDATE person SET "faceAssetId"=NULL;
. Make a backup of your database before. It's the id of the asset used to generate the feature photo for your people. Unless you reassign a face to a person it won't change your current people feature photos.
Thank you - this worked and upgraded environment started no issues:
UPDATE person SET "faceAssetId"=NULL;
Now in person
I have nothing in faceAssetId
(clearly), but I do not understand the impact of this. The face feature photos seem to display fine. Could you please explain how this could affect me long term, or why it is no problem to leave like this?
Thanks again for all of your help @martabal
Yes, to generate the feature photo for the person thumbnail, we have to know which asset to use. Your people already have a feature photo so it does not affect them.
I think it will only affect the new re-assign feature : let's say you have person A and person B. If you reassign a face from person A to person B, the server will check if person B has a feature photo (because you don't want a person without a feature photo). In your case person B has a feature photo but the server will consider it has not so it will change the feature photo from person B with a random face of person B. The solution to avoid this is it to manually set the feature photo with "Change feature photo" on the person page.
Really sorry the inconvenience, I don't really understand what could have caused this issue :thinking:
Out of curiosity, since when do you run Immich ? I suspect this issue to affect users who run Immich since the person feature was introduced
I started running it about 6 months ago. Using much more (actually it's now how I look at my photos each day!) that Libraries are available, as all my pictures are on the filesystem with directory names curated. But, to answer your question, I made a fresh setup from scratch and rescanned all of my photos after the Libraries feature came. So, since then... (when did the person feature come?)
Thank you so much for your kind help and explanations - really appreciated.
Hey, if I may post to this thread; I am having the exact same issue. I am using Immich for 2-3 Months now and started from scratch around 1 month ago. So I went through all faces again and now it won't let me update because of the issues that come up as stated in the opening post.
May I ask how I execute UPDATE person SET "faceAssetId"=NULL;? Do I need to input something before executing it?
Well both of you are recent Immich users. I'm wondering what I missed in the migration script then.
To solve this issue there's 2 solutions :
docker exec -it immich_postgres psql -U postgres -d immich -c 'UPDATE person SET "faceAssetId"=NULL;'
Thanks for your help. I used the second option and it works.
EDIT: I noticed that editing locations do not work, I assume it has to do with those complications as well.. (?)
No I don't think it has something to do with this issue. Note that you can not edit metadata for assets which are in external libraries
The bug
After upgrading to v1.90.2, I can no longer start the container, even after waiting 15-20 minutes for potential migrations etc. Detailed log file attached below, but not sure what to do to resolve this. The only thing I did was run
docker compose pull
The OS that Immich Server is running on
Debian 12 latest updates applied
Version of Immich Server
v1.90.2
Version of Immich Mobile App
N/A
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Additional information
Logs from
docker compose logs
- this just repeats over and over endlessly: