Immich Go hanging up whenever there is an error

[MattSokii]

can someone please help me with this.
Im trying to upload a library of 40K photos and this issue happenes every 200-500 files or even sooner. I cant be sitting in front of my mac for days restarting Immich go every time this happens

most common error is this
│2025-02-12 06:18:13 ERR upload error file=takeout-20250209T204248Z-005:Takeout/Google Photos/XXXXXXXXX/IMG_5616.HEIC error=updateAsset, PUT, http://192.168.1.164:2283/api/assets/b77cb63e-e26e-4cae-ae11-9fac6ad0083f │
│Put "http://192.168.1.164:2283/api/assets/b77cb63e-e26e-4cae-ae11-9fac6ad0083f": EOF │
immich go just stops uploading files.
Im using synology 224+ with basic docker immich install│

[simulot]

Could you get the log files from immich-go and from the server side. Look for Error 500 Internal Server Error

You can relaunch immich-go with following options and share the logs

--log-level=DEBUG
--api-trace

[orange-buffalo]

Not sure if it is the same issue, but symptoms are very similar for me. I see these log entries, after which the upload hangs:

2025-02-16 12:20:53 INF server has same asset file=takeout-20250213T054142Z-002:Takeout/Google Photos/Photos from 2018/IMG_20180913_161230506.jpg reason=An asset with the same name:"IMG_20180913_161230506.jpg", date:"2018-09-13 16:12:30" and size:3.2 MB exists on the server. No need to upload.
2025-02-16 12:20:53 INF Tagged file=takeout-20250213T054142Z-002:Takeout/Google Photos/Photos from 2018/IMG_20180913_161230506.jpg tags=takeout-20250213T054142Z
2025-02-16 12:20:53 ERR upload error file=takeout-20250213T054142Z-002:Takeout/Google Photos/Photos from 2018/IMG_20180913_161230506(1).jpg error=AssetReplace, PUT, http://192.168.1.160:2283/api/assets/085d445b-cf8e-4154-9c6a-4192428fb097/original, 400 Bad Request
Not found or no asset.update access

2025-02-16 12:20:53 INF Stacked file=takeout-20250213T054142Z-002:Takeout/Google Photos/Photos from 2018/IMG_20180913_161230506.jpg
2025-02-16 12:20:53 INF Stacked file=takeout-20250213T054142Z-002:Takeout/Google Photos/Photos from 2018/IMG_20180913_161230506(1).jpg

On the server side, the error is similar:

[Nest] 17  - 02/16/2025, 12:20:53 PM   ERROR [Api:AssetMediaService~stz5vfjm] Error uploading file BadRequestException: Not found or no asset.update access
BadRequestException: Not found or no asset.update access
    at requireAccess (/usr/src/app/dist/utils/access.js:24:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async AssetMediaService.replaceAsset (/usr/src/app/dist/services/asset-media.service.js:111:13)
    at async AssetMediaController.replaceAsset (/usr/src/app/dist/controllers/asset-media.controller.js:51:29)

[simulot]

Thank you.

[orange-buffalo]

@simulot I did some research of the failing data. In my case, the problem is that a user, who is uploading photos, has partner sharing established with another user, who already has one of the photos from the group. So when current user tries to update the existing asset to create a stack with the newly discovered burst photo from this group, they fail as the existing asset belongs to another user (and is read-only for current user via partner sharing). This setup comes from partner sharing in Google Photos, where one of the partners has "store photos in my library" option enabled, so duplicates are created in one of the accounts.

I understand that this might not be the top-priority case to support. On the other hand, many of those who migrate to Immich are families with partner sharing enabled in Google Photos, so it might be not an extremely rare occasion. In my opinion, there are at least two options how this could be gracefully handled:

1. Provide an additional option for --manage-burst like keepIndividual that would not attempt creating stacks at all. Personally I would prefer it, as it would allow me later to check for duplicates in Immich and reduce my library size.
2. Before creating a stack, verify access to the existing assets and exclude them from the group if read-only. Then skip stack creation if less than two photos left, upload remaining photo (if any) individually.

Wdyt, does it make sense for you?

[bbatod]

I am running into similar error as well for stacks. I already uploaded by Google Take Out from my account and now trying to do the same from another person's Google Take Out to their own Immich account. Following is the error that I got.

2025-02-20 18:24:11 INF server has same asset file=takeout-20250101T232843Z-008:Takeout/Google Photos/Photos from 2014/IMG_8194(2).JPG reason=the server has this file
2025-02-20 18:24:11 ERR upload error file=takeout-20250101T232843Z-008:Takeout/Google Photos/Photos from 2014/IMG_8194(2).JPG error=updateAsset, PUT, http://192.168.1.210:2283/api/assets/f32af9ab-44f5-4772-a27c-50896621baaa, 500 Internal Server Error
Internal server error

2025-02-20 18:24:11 INF Stacked file=takeout-20250101T232843Z-008:Takeout/Google Photos/Photos from 2014/IMG_8194(1).JPG
2025-02-20 18:24:11 INF Stacked file=takeout-20250101T232843Z-008:Takeout/Google Photos/Photos from 2014/IMG_8194(2).JPG

Any workarounds that I could try for this?

[orange-buffalo]

For me this error did not appear for very duplicate. I ended up with deleting problematic copies manually from Immich UI of the first account, and then re-running the import for the second account. On 30k total photos I've got about 5 such errors. There were more in the logs, but on those the import did not hang, and I actually had those photos imported into Immich.

[simulot]

@orange-buffalo
Thank you for these insights. This is the first time I have a plausible cause for this problem. I hadn't considered the possibility that one of the photos in the stack might already be present for another account. I will verify this with a test instance.

For me, this error did not appear for very duplicate.

This comment suggests there might be more causes to this problem.

@bbatod
Considering @orange-buffalo's findings, you can completely disable the stacking options using these undocumented options:
--manage-burst= --manage-heic-jpeg= --manage-raw-jpeg=

It appears I forgot to implement the "ignore" option value, but an empty value works with the current version. Let me know if this helps to avoid the error 500. This will confirm the cause of the problem.

Thank you for your inputs.

[simulot]

I haven't yet explored the possible relation between the hangs and the possible existence of duplicate photos in other users accounts.

However, I just have fixed a very similar error in a different context:

1. A takeout containing "supplemental.metadata.json" was uploaded using an older version of Immich-go. Some photos were left unprocessed at that time.
2. The same takeout was later uploaded using a more recent version of Immich-go. The previously unprocessed photos were then processed but mistakenly considered as superior versions of already uploaded photos. A supposedly better image should replace the existing one.
3. A misunderstanding of the API call replaceAsset led to errors in tagging and album management.