Request failed with status code 404 - immich CLI
Hello,
When I upload assets that are already on the server to an existing album I get the following error " Request failed with status code 404" for every asset that is already on the server.
Immich CLI is run locally from my laptop and has version 0.41.0.
Immich version: v1.83.0
I tried to search GitHub for an issue related to this behaviour but I couldn't find out.
Does anyone else experience the same issue?
26 Replies
I assume these are duplicated files, you can check the server logs, it should prompt you that there are identical assets already
I also assume that these are duplicate files, based on the number of error messages in the CLI
I cannot find anything in the server log of the immich stack
Do I need to turn up the error log for the server container up or?
Hmm, no
Can you try draging one of those 14 files to upload over the web interface to see if it get rejected?
the file is rejected as duplicate
okay, that works as intended
There is no log entry in the server container. I changed the number of lines displayed from 1000 to 25 so it's easier to view
The functionality seems to be working ok
I mean for the CLI
is this on Windows?
Ah it might be logs from the database actually
I'm just wondering if the error message for the duplicate files is intended or not
sorry
I usually have all the logs from all containers log out so I might have mistaken it comes from the server
the database would print some log about duplicated
you are right, there are 3 new log entries in the database container when I upload a duplicate image via web interface
The reason why I raised this question was to find out if I should raise an issue on GitHub regarding the strange error code returned on CLI when attempting to upload a duplicate asset or is this an intended behaviour. In the past it didn't return this message when I uploaded duplicate files.
This happens to me recently after I change some album from the web interface without changing the folder name on the file system
did you do something similar?
before uploading the files, I changed the storage template from the preset one to the one from the image below
I ran the "Storage template migration" job and waited for it to finish
I even checked manually in the library folder and saw that all photos were moved from old template folders to new ones
then I ran some CLI commands to sync new photos from my main photo library to immich
immich upload --key xxx --server http://192.168.0.101:2283/api --yes --recursive --threads 20 --album '2006.07 - Poze cu Miky, pisica lui Adi' /home/sitram/mounts/data/photos/'2006.07 - Poze cu Miky, pisica lui Adi'
this is an example of a command that I run
in my main photo library I had a new folder added which. The photos from this folder were not on immich. The CLI command that I ran to add the photos from that folder to a new album with the same name, executed succesfully.
for the above command, the photos were already uploaded in immich a while ago and the album was created
The CLI comands I run from ArchLinux. The image with docker logs are taken from Portainer
I was coming here to ask the same question 🙂 I have add that issue for the last few days and been trying to understand what was wrong until I checked the DB logs this morning and figured out it was duplicates. I then tried uploading from the web interface and confirmed these were actual duplicate.
I end up with the same question though, why do I see that generic error now that I did not see before. Is this really the 1st time I upload duplicate? I would be surprised as I already do have more than 250k photos in ly libraries.
I think the recent update on the server might have change some response code that cause the CLI is not on the same pace anymore
😄
May I suggest to give a try to immich-go?
https://github.com/simulot/immich-go
Well... I am already in the process of downloading ~180Gb of Google Photos Takeout Archives so I may as well give immich-go a try! Merci Jean François!
thanks, I'd pleased to how the import has worked
Amazingly well 🙂
@Alex I have some reports about timeouts when calling /api/asset with big library and low powered servers. Is it possible to get assets by chunks?
I think that would be great to add that as a request option
Because for the mobile app we are seeing somewhat the same behavior for a really big library