immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

High-priority: Add an option to limit concurrent uploads in the mobile app to fix timeouts and failed backups #6948

New Issue
Closed
opened 2026-02-05 12:39:46 +03:00 by OVERLORD · 2 comments
OVERLORD commented 2026-02-05 12:39:46 +03:00
Owner
Copy Link

Originally created by @paolocorradini on GitHub (Aug 24, 2025).

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

  • Yes

The bug

Hey Immich Team and Community,

First off, thank you for all the incredible work on this project. Immich is a fantastic solution, and the mobile app is a key part of its value.

I'm writing to report a critical issue that's severely affecting the user experience, particularly for those with large files (videos) or slower internet connections:

The Problem

When the Immich mobile app tries to upload many large files at once, it often leads to a few problems:

Timeouts: Large videos that take a long time to upload can time out, causing the upload to fail.

Network Saturation: The app consumes all available upload bandwidth, making the network unusable for other devices.

Redundant/Failed Uploads: After a timeout, the app often gets stuck in a loop, trying to re-upload the same files that have already partially failed. This leads to wasted bandwidth, battery drain, and an incomplete backup.

Since there is currently no option to control the number of concurrent uploads in the app, users are left without a way to mitigate this issue. This can be a major pain point and a dealbreaker for many, as it undermines the core function of the app: reliable and complete photo backup.

The Proposed Solution

I propose adding a "Concurrent Uploads" setting in the mobile app. This feature would allow users to manually set the number of simultaneous file uploads. This is already a feature in the Immich CLI, so the underlying logic might be reusable.

Benefits of this feature:

Increased Reliability: Users can set the concurrency to "1" for a more stable and reliable upload, especially for large files. This prevents timeouts and ensures that every file is successfully backed up.

Better Network Performance: It frees up bandwidth for other users and devices on the network, improving the overall home internet experience.

Improved User Experience: It eliminates the frustration of redundant and failed uploads, making the backup process more predictable and trustworthy.

This change would transform Immich from a tool that sometimes struggles with large files to a robust and reliable backup solution for all users, regardless of their connection speed.

Thank you for your consideration. I believe this is a crucial improvement for the project.

The OS that Immich Server is running on

truenas docker

Version of Immich Server

v1.19.18

Version of Immich Mobile App

v.1.139.2

Platform with the issue

  • Mobile
  • Server
  • Web

Device make and model

oppo reno 10 pro 5G

Your docker-compose.yml content

non serve

Your .env content

non lo so

Reproduction steps

...

Relevant log output

Additional information

No response

Originally created by @paolocorradini on GitHub (Aug 24, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug Hey Immich Team and Community, First off, thank you for all the incredible work on this project. Immich is a fantastic solution, and the mobile app is a key part of its value. I'm writing to report a critical issue that's severely affecting the user experience, particularly for those with large files (videos) or slower internet connections: The Problem When the Immich mobile app tries to upload many large files at once, it often leads to a few problems: Timeouts: Large videos that take a long time to upload can time out, causing the upload to fail. Network Saturation: The app consumes all available upload bandwidth, making the network unusable for other devices. Redundant/Failed Uploads: After a timeout, the app often gets stuck in a loop, trying to re-upload the same files that have already partially failed. This leads to wasted bandwidth, battery drain, and an incomplete backup. Since there is currently no option to control the number of concurrent uploads in the app, users are left without a way to mitigate this issue. This can be a major pain point and a dealbreaker for many, as it undermines the core function of the app: reliable and complete photo backup. The Proposed Solution I propose adding a "Concurrent Uploads" setting in the mobile app. This feature would allow users to manually set the number of simultaneous file uploads. This is already a feature in the Immich CLI, so the underlying logic might be reusable. Benefits of this feature: Increased Reliability: Users can set the concurrency to "1" for a more stable and reliable upload, especially for large files. This prevents timeouts and ensures that every file is successfully backed up. Better Network Performance: It frees up bandwidth for other users and devices on the network, improving the overall home internet experience. Improved User Experience: It eliminates the frustration of redundant and failed uploads, making the backup process more predictable and trustworthy. This change would transform Immich from a tool that sometimes struggles with large files to a robust and reliable backup solution for all users, regardless of their connection speed. Thank you for your consideration. I believe this is a crucial improvement for the project. ### The OS that Immich Server is running on truenas docker ### Version of Immich Server v1.19.18 ### Version of Immich Mobile App v.1.139.2 ### Platform with the issue - [x] Mobile - [ ] Server - [ ] Web ### Device make and model oppo reno 10 pro 5G ### Your docker-compose.yml content ```YAML non serve ``` ### Your .env content ```Shell non lo so ``` ### Reproduction steps 1. 2. 3. ... ### Relevant log output ```shell ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 12:39:49 +03:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 24, 2025):

This issue has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.

@github-actions[bot] commented on GitHub (Aug 24, 2025): This issue has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.
OVERLORD commented 2026-02-05 12:39:50 +03:00
Author
Owner
Copy Link

@paolocorradini commented on GitHub (Aug 24, 2025):

There are no such discussions and I would appreciate it if you could reopen the Trend

@paolocorradini commented on GitHub (Aug 24, 2025): There are no such discussions and I would appreciate it if you could reopen the Trend
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#6948
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?