starred/immich

Fork 0

mirror of https://github.com/immich-app/immich.git synced 2026-03-02 22:57:45 -05:00

App keeps trying failed uploads #6304

New issue

Closed

opened 2026-02-20 04:10:36 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-20 04:10:36 -05:00

Owner

Originally created by @Cansero on GitHub (Aug 6, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

The bug

I use cloudflare, so I expect files above 100mb to fail upon trying to upload. The problem here is that Immich app tries to upload the big file, i.e. a videa, fails, upload a normal photo successfully and then tries again to upload the failed video and so on delaying the whole upload process.
All 3 parallel uploads follow the same behavior.
In my case I only had 3 videos above the 100mb threshold to fail, so I don't know what would've happened if I there were more than the number of parallel uploads

The OS that Immich Server is running on

Ubuntu 24.04.02

Version of Immich Server

1.136.0

Version of Immich Mobile App

1.137.2 build.213

Platform with the issue

Server
Web
Mobile

Your docker-compose.yml content

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, openvino] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:905c4ee67b8e0aa955331960d2aa745781e6bd89afc44a8584bfd13bc890f0ae
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.3.0-pgvectors0.2.0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    restart: always

volumes:
  model-cache:

Your .env content

# The location where your uploaded files are stored
UPLOAD_LOCATION=/home/cansero/docker/immich/library
# The location where your database files are stored
DB_DATA_LOCATION=./postgres

# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
TZ=America/Toronto

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=supersecretpassword

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

Using reverse proxy for the server like Cloudflare
Upload assets like photos and at least one above 100 mb to trigger a failed upload

Relevant log output

Additional information

No, the password on the .env is not my real password, just in case

Originally created by @Cansero on GitHub (Aug 6, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug I use cloudflare, so I expect files above 100mb to fail upon trying to upload. The problem here is that Immich app tries to upload the big file, i.e. a videa, fails, upload a normal photo successfully and then tries again to upload the failed video and so on delaying the whole upload process. All 3 parallel uploads follow the same behavior. In my case I only had 3 videos above the 100mb threshold to fail, so I don't know what would've happened if I there were more than the number of parallel uploads ### The OS that Immich Server is running on Ubuntu 24.04.02 ### Version of Immich Server 1.136.0 ### Version of Immich Mobile App 1.137.2 build.213 ### Platform with the issue - [ ] Server - [ ] Web - [x] Mobile ### Your docker-compose.yml content ```YAML name: immich services: immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} # extends: # file: hwaccel.transcoding.yml # service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding volumes: # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file - ${UPLOAD_LOCATION}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - '2283:2283' depends_on: - redis - database restart: always healthcheck: disable: false immich-machine-learning: container_name: immich_machine_learning # For hardware acceleration, add one of -[armnn, cuda, openvino] to the image tag. # Example tag: ${IMMICH_VERSION:-release}-cuda image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration # file: hwaccel.ml.yml # service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable volumes: - model-cache:/cache env_file: - .env restart: always healthcheck: disable: false redis: container_name: immich_redis image: docker.io/redis:6.2-alpine@sha256:905c4ee67b8e0aa955331960d2aa745781e6bd89afc44a8584bfd13bc890f0ae healthcheck: test: redis-cli ping || exit 1 restart: always database: container_name: immich_postgres image: ghcr.io/immich-app/postgres:14-vectorchord0.3.0-pgvectors0.2.0 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' volumes: # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file - ${DB_DATA_LOCATION}:/var/lib/postgresql/data restart: always volumes: model-cache: ``` ### Your .env content ```Shell # The location where your uploaded files are stored UPLOAD_LOCATION=/home/cansero/docker/immich/library # The location where your database files are stored DB_DATA_LOCATION=./postgres # To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List TZ=America/Toronto # The Immich version to use. You can pin this to a specific version like "v1.71.0" IMMICH_VERSION=release # Connection secret for postgres. You should change it to a random password # Please use only the characters `A-Za-z0-9`, without special characters or spaces DB_PASSWORD=supersecretpassword # The values below this line do not need to be changed ################################################################################### DB_USERNAME=postgres DB_DATABASE_NAME=immich ``` ### Reproduction steps 1. *Using reverse proxy for the server like Cloudflare* 2. Upload assets like photos and at least one above 100 mb to trigger a failed upload ### Relevant log output ```shell ``` ### Additional information No, the password on the .env is not my real password, just in case

deekerman

2026-02-20 04:10:36 -05:00

closed this issue
added the
📱mobile
label

deekerman commented

2026-02-20 04:10:37 -05:00

Author

Owner

@alextran1502 commented on GitHub (Aug 6, 2025):

Trying a failed upload is the expected behavior to ensure assets get uploaded to the server once the issues are resolved

@alextran1502 commented on GitHub (Aug 6, 2025): Trying a failed upload is the expected behavior to ensure assets get uploaded to the server once the issues are resolved

deekerman commented

2026-02-20 04:10:37 -05:00

Author

Owner

@Cansero commented on GitHub (Aug 6, 2025):

What I mean is the app tries, fails, then uploads one asset successfully, and then tries once again the previously failed asset making the process too long.
When that happen, I had 3 videos and 10 photos, the app tried to upload the 3 videos once before each photo taking way longer than it should for the photos to be backed up.

Before the beta back up, the app tries, fails, and tries once again after all other assets where finished. Wouldn't that be the expected behavior as well?

@Cansero commented on GitHub (Aug 6, 2025): What I mean is the app tries, fails, then uploads one asset successfully, and then tries once again the previously failed asset making the process too long. When that happen, I had 3 videos and 10 photos, the app tried to upload the 3 videos once before each photo taking way longer than it should for the photos to be backed up. Before the beta back up, the app tries, fails, and tries once again after all other assets where finished. Wouldn't that be the expected behavior as well?

deekerman commented

2026-02-20 04:10:37 -05:00

Author

Owner

@Hinfty commented on GitHub (Aug 7, 2025):

Would disabling uploading videos on mobile data make sense in this setup? Once in the home network the videos would upload just fine, assuming the server is located there.
Generally, trying to upload "un-uploadable" files does not make sense.
In a reliable setup, the 100mb restriction would need to be known and observed by Immich, which would need a feature request.

@Hinfty commented on GitHub (Aug 7, 2025): Would disabling uploading videos on mobile data make sense in this setup? Once in the home network the videos would upload just fine, assuming the server is located there. Generally, trying to upload "un-uploadable" files does not make sense. In a reliable setup, the 100mb restriction would need to be known and observed by Immich, which would need a feature request.

deekerman commented

2026-02-20 04:10:37 -05:00

Author

Owner

@alextran1502 commented on GitHub (Aug 7, 2025):

In a reliable setup, the 100mb restriction would need to be known and observed by Immich, which would need a feature request.

This is usually not easy to know because the app doesn't know which tunnel it is being routed to. And if so, CF will need to send back a specific error code that corresponds to the rejection of 100MB limit. Modifying Immich to work with CF is not a very good priority for the project in my opinion.

@alextran1502 commented on GitHub (Aug 7, 2025): > In a reliable setup, the 100mb restriction would need to be known and observed by Immich, which would need a feature request. This is usually not easy to know because the app doesn't know which tunnel it is being routed to. And if so, CF will need to send back a specific error code that corresponds to the rejection of 100MB limit. Modifying Immich to work with CF is not a very good priority for the project in my opinion.

deekerman commented

2026-02-20 04:10:37 -05:00

Author

Owner

@Cansero commented on GitHub (Aug 7, 2025):

The only time I've seen a message pointing at CF as the reason of a failed upload was when trying to upload a video with the Immich cli and even then the message didn't say it was the size, just something with CF.
Also, even if you fix it with CF, any other tunnel may send a different error message that would have to be addressed individually, I also don't think that is the way to go.

Anyway, that is still not the problem I pointed at, rather the way it was handle the failed uploads.
For example, let's say we have Vid 1 and Pic 1 to Pic 7, the upload process was as follow:

Vid 1 - Failed
Pic 1 - Success
Vid 1 - Failed
Pic 2 - Success
Vid 1 - Failed
Pic 3 - Success
Vid 1 - Failed
Pic 4 - Success
Vid 1 - Failed
Pic 5 - Success
Vid 1 - Failed
Pic 6 - Success
Vid 1 - Failed
Pic 7 - Success
Vid 1 - Failed

Rather than:

Vid 1 - Failed
Pic 1 - Success
Pic 2 - Success
Pic 3 - Success
Pic 4 - Success
Pic 5 - Success
Pic 6 - Success
Pic 7 - Success
Vid 1 - Failed

Previous to the beta backup, the upload process was like the last one. wouldn't try the failed uploads not until it tried all the other assets first. That is the problem I'm trying to notify.

@Cansero commented on GitHub (Aug 7, 2025): The only time I've seen a message pointing at CF as the reason of a failed upload was when trying to upload a video with the Immich cli and even then the message didn't say it was the size, just something with CF. Also, even if you fix it with CF, any other tunnel may send a different error message that would have to be addressed individually, I also don't think that is the way to go. Anyway, that is still not the problem I pointed at, rather the way it was handle the failed uploads. For example, let's say we have Vid 1 and Pic 1 to Pic 7, the upload process was as follow: Vid 1 - Failed Pic 1 - Success Vid 1 - Failed Pic 2 - Success Vid 1 - Failed Pic 3 - Success Vid 1 - Failed Pic 4 - Success Vid 1 - Failed Pic 5 - Success Vid 1 - Failed Pic 6 - Success Vid 1 - Failed Pic 7 - Success Vid 1 - Failed Rather than: Vid 1 - Failed Pic 1 - Success Pic 2 - Success Pic 3 - Success Pic 4 - Success Pic 5 - Success Pic 6 - Success Pic 7 - Success Vid 1 - Failed Previous to the beta backup, the upload process was like the last one. wouldn't try the failed uploads not until it tried all the other assets first. That is the problem I'm trying to notify.

deekerman commented

2026-02-20 04:10:37 -05:00

Author

Owner

@jondycz commented on GitHub (Aug 8, 2025):

Uploading the files in chunks would not only improve reliability of uploads, but would also enable resumable uploads and provide an elegant solution that is not cloudflare specific. Nextcloud and filebrowser already do this. Though I'm uncertain how this would work with background workers. Is this feature part of the "better background backups" roadmap? I wouldn't call backing up a 5GB file that fails due to the background thread being killed by battery saver and having to re-upload to whole file "reliable"

@jondycz commented on GitHub (Aug 8, 2025): Uploading the files in chunks would not only improve reliability of uploads, but would also enable resumable uploads and provide an elegant solution that is not cloudflare specific. Nextcloud and filebrowser already do this. Though I'm uncertain how this would work with background workers. Is this feature part of the "better background backups" roadmap? I wouldn't call backing up a 5GB file that fails due to the background thread being killed by battery saver and having to re-upload to whole file "reliable"

deekerman commented

2026-02-20 04:10:38 -05:00

Author

Owner

@Hinfty commented on GitHub (Aug 8, 2025):

This is usually not easy to know because the app doesn't know which tunnel it is being routed to. And if so, CF will need to send back a specific error code that corresponds to the rejection of 100MB limit.

This would be information that the user provides in the setting. Eg. max file size to be uploaded when on mobile network.
This might be a setting that not only CF users would use, but also users with restricted plans. That being said, it's also not a priority for me personally.

@Hinfty commented on GitHub (Aug 8, 2025): >This is usually not easy to know because the app doesn't know which tunnel it is being routed to. And if so, CF will need to send back a specific error code that corresponds to the rejection of 100MB limit. This would be information that the user provides in the setting. Eg. max file size to be uploaded when on mobile network. This might be a setting that not only CF users would use, but also users with restricted plans. That being said, it's also not a priority for me personally.

deekerman commented

2026-02-20 04:10:38 -05:00

Author

Owner

@bo0tzz commented on GitHub (Sep 18, 2025):

I'm going to close this issue, as discussed the proper fix is chunked uploading (#1674)

@bo0tzz commented on GitHub (Sep 18, 2025): I'm going to close this issue, as discussed the proper fix is chunked uploading (#1674)

deekerman commented

2026-02-20 04:10:38 -05:00

Author

Owner

@jondycz commented on GitHub (Sep 18, 2025):

Let's hope the "proper fix" doesn't take another 2 years to implement

@jondycz commented on GitHub (Sep 18, 2025): Let's hope the "proper fix" doesn't take another 2 years to implement

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/immich#6304

No description provided.

Rows
Columns