Navigating away and back to Backup view resets upload

deekerman commented

2026-02-20 02:17:51 -05:00

Owner

Originally created by @szmarczak on GitHub (Sep 15, 2024).

The bug

Android.

Click the Cloud icon while you're uploading some large file. Make sure the progress is at least a few %.
Navigate away to another app. Wait a second or two.
Navigate back.
The progress resets.

The progress resets every time you navigate away and back, not only just the Backup screen.

The OS that Immich Server is running on

Alpine Linux v3.19

Version of Immich Server

1.112.1

Version of Immich Mobile App

1.114.0

Platform with the issue

Server
Web
Mobile

Your docker-compose.yml content

#
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#

name: immich

services:
  cloudflared:
    restart: always
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run --token REDACTED

  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    extends:
      file: hwaccel.transcoding.yml
      service: vaapi # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - 2283:3001
    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}-openvino
    extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
      file: hwaccel.ml.yml
      service: openvino # 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

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

  database:
    container_name: immich_postgres
    image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo "checksum failure count is $$Chksum"; [ "$$Chksum" = '0' ] || exit 1
      interval: 5m
      start_interval: 30s
      start_period: 5m
    command: ["postgres", "-c", "shared_preload_libraries=vectors.so", "-c", 'search_path="$$user", public, vectors', "-c", "logging_collector=on", "-c", "max_wal_size=2GB", "-c", "shared_buffers=512MB", "-c", "wal_compression=on"]
    restart: always

volumes:
  model-cache:

Your .env content

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION=./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=Etc/UTC

# 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
DB_PASSWORD=REDACTED

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

Reproduction steps

Above.

Relevant log output

No response

Additional information

This is an OS issue, it’s not possible for Immich to retain the foreground permission for backup without focus. The background task is triggered separately. - @mmomjian

No, it's not. Use your mind. This does not happen with Google Photos. Rings a bell? ding ding ding partial uploads ding ding ding. Save the progress on the server and resume when the job restarts.

The issue is not about the job restarting, it's about the upload starting from zero.

Originally created by @szmarczak on GitHub (Sep 15, 2024). ### The bug Android. 1. Click the Cloud icon while you're uploading some large file. Make sure the progress is at least a few %. 2. Navigate away to another app. Wait a second or two. 3. Navigate back. 4. The progress resets. The progress resets every time you navigate away and back, not only just the Backup screen. ### The OS that Immich Server is running on Alpine Linux v3.19 ### Version of Immich Server 1.112.1 ### Version of Immich Mobile App 1.114.0 ### Platform with the issue - [ ] Server - [ ] Web - [X] Mobile ### Your docker-compose.yml content ```YAML # # WARNING: Make sure to use the docker-compose.yml of the current release: # # https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml # # The compose file on main may not be compatible with the latest release. # name: immich services: cloudflared: restart: always image: cloudflare/cloudflared:latest command: tunnel --no-autoupdate run --token REDACTED immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} extends: file: hwaccel.transcoding.yml service: vaapi # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding volumes: - ${UPLOAD_LOCATION}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - 2283:3001 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}-openvino extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration file: hwaccel.ml.yml service: openvino # 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 redis: container_name: immich_redis image: docker.io/redis:6.2-alpine@sha256:e3b17ba9479deec4b7d1eeec1548a253acc5374d68d3b27937fcfe4df8d18c7e healthcheck: test: redis-cli ping || exit 1 restart: always database: container_name: immich_postgres image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' volumes: - ${DB_DATA_LOCATION}:/var/lib/postgresql/data healthcheck: test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo "checksum failure count is $$Chksum"; [ "$$Chksum" = '0' ] || exit 1 interval: 5m start_interval: 30s start_period: 5m command: ["postgres", "-c", "shared_preload_libraries=vectors.so", "-c", 'search_path="$$user", public, vectors', "-c", "logging_collector=on", "-c", "max_wal_size=2GB", "-c", "shared_buffers=512MB", "-c", "wal_compression=on"] restart: always volumes: model-cache: ``` ### Your .env content ```Shell # You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables # The location where your uploaded files are stored UPLOAD_LOCATION=./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=Etc/UTC # 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 DB_PASSWORD=REDACTED # The values below this line do not need to be changed ################################################################################### DB_USERNAME=REDACTED DB_DATABASE_NAME=REDACTED ``` ### Reproduction steps Above. ### Relevant log output _No response_ ### Additional information > This is an OS issue, it’s not possible for Immich to retain the foreground permission for backup without focus. The background task is triggered separately. - [@mmomjian](https://github.com/immich-app/immich/discussions/12703#discussioncomment-10653131) No, it's not. Use your mind. This does not happen with Google Photos. Rings a bell? ding ding ding partial uploads ding ding ding. Save the progress on the server and resume when the job restarts. The issue is not about the job restarting, it's about the upload starting from zero.

deekerman closed this issue

2026-02-20 02:17:52 -05:00

deekerman commented

2026-02-20 02:17:53 -05:00

Author

Owner

@alextran1502 commented on GitHub (Sep 15, 2024):

I saw you opened an issue, get closed and opened again.

This is the current behavior of Immich, hence it is not a bug. You can see it as the current limitation of the backup system, and there are feature requests about this mechanism to continue on the background

@alextran1502 commented on GitHub (Sep 15, 2024): I saw you opened an issue, get closed and opened again. This is the current behavior of Immich, hence it is not a bug. You can see it as the current limitation of the backup system, and there are feature requests about this mechanism to continue on the background You can read more here https://immich.app/docs/FAQ#why-does-foreground-backup-stop-when-i-navigate-away-from-the-app-shouldnt-it-transfer-the-job-to-background-backup

deekerman commented

2026-02-20 02:17:53 -05:00

Author

Owner

@szmarczak commented on GitHub (Sep 15, 2024):

I saw you opened an issue, get closed and opened again.

Correct, because you're wrong. Don't convert this to discussion. It's not a discussion, it's a bug report.

This is the current behavior of Immich, hence it is not a bug.

Reproducible bugs ARE always current behavior. This is not an excuse and this is the shittest explaination I've ever heard.

You can see it as the current limitation of the backup system

The limitation IS a bug. This is unwanted behavior and unwanted behaviors are bugs. Limitation is something that can't be worked around by design. This is NOT the case.

You can read more here https://immich.app/docs/FAQ#why-does-foreground-backup-stop-when-i-navigate-away-from-the-app-shouldnt-it-transfer-the-job-to-background-backup

This explains how the jobs work internally. I don't fucking care about how you handle this internally. I care about my uploads and I'd like Immich to do its magic. Like I said before, if Google Photos can do this, so can you. TL;DR: store partial uploads

@szmarczak commented on GitHub (Sep 15, 2024): > I saw you opened an issue, get closed and opened again. Correct, because you're wrong. Don't convert this to discussion. It's not a discussion, it's a bug report. > This is the current behavior of Immich, hence it is not a bug. Reproducible bugs ***ARE*** always current behavior. This is not an excuse and this is the shittest explaination I've ever heard. > You can see it as the current limitation of the backup system The limitation IS a bug. This is unwanted behavior and unwanted behaviors are bugs. Limitation is something that can't be worked around by design. This is NOT the case. > You can read more here https://immich.app/docs/FAQ#why-does-foreground-backup-stop-when-i-navigate-away-from-the-app-shouldnt-it-transfer-the-job-to-background-backup This explains how the jobs work internally. I don't fucking care about how you handle this internally. I care about my uploads and I'd like Immich to do its magic. Like I said before, if Google Photos can do this, so can you. TL;DR: store partial uploads

deekerman commented

2026-02-20 02:17:53 -05:00

Author

Owner

@bo0tzz commented on GitHub (Sep 15, 2024):

@szmarczak regardless of the details of whether or not this is a bug, you're being rude and obtuse about it and that's not welcome here.

@bo0tzz commented on GitHub (Sep 15, 2024): @szmarczak regardless of the details of whether or not this is a bug, you're being rude and obtuse about it and that's not welcome here.

deekerman commented

2026-02-20 02:17:54 -05:00

Author

Owner

@alextran1502 commented on GitHub (Sep 15, 2024):

@szmarczak I don't think we need to get heated over this. We choose a certain way to manage bugs and feature requests. If, in the code, we implement partial backup and if you switch screens, it doesn't continue, then we would consider that a bug. Instead, we specifically implemented two distinct behaviors between foreground and background backup. That is why your issue is closed and considered as a feature request. And we are also aware of such request.

We are a small team, and we want to keep things on top of our heads so we can track bugs correctly.

I believe you are a developer, too, and probably understand that yelling at people is not a good idea; our only rule for the Immich community is to be nice. So let's do that.

@alextran1502 commented on GitHub (Sep 15, 2024): @szmarczak I don't think we need to get heated over this. We choose a certain way to manage bugs and feature requests. If, in the code, we implement partial backup and if you switch screens, it doesn't continue, then we would consider that a bug. Instead, we specifically implemented two distinct behaviors between foreground and background backup. That is why your issue is closed and considered as a feature request. And we are also aware of such request. We are a small team, and we want to keep things on top of our heads so we can track bugs correctly. I believe you are a developer, too, and probably understand that yelling at people is not a good idea; our only rule for the Immich community is to be nice. So let's do that.

deekerman commented

2026-02-20 02:17:54 -05:00

Author

Owner

@szmarczak commented on GitHub (Sep 15, 2024):

Feature request = adds new functionality.
Bug report = fixes something that works incorrectly.

Fixing a bug often requires adding new code, and new code does not necessarily mean new features.

The functionality here is: uploading. Therefore no new functionality is added. You are fixing something that already exists.

Look at it this way: you're playing a game that needs days to be completed. You have made some progress, you minimize the game, reopen it, and the entire progress is gone. No person would consider this ever as a missing feature because state preservation is expected. This is a bug.

Even in universities missing state preservation (in context of mobile applications) is considered a bug and not a missing feature. So I'm surprised immich thinks otherwise. If you switched tabs in a browser and the form you just completed would reset... it's a bug, not a feature.

The end user need not know the inner workings. The functionality is simple: upload, download, organize.

If you were to split the functionality into smaller and smaller parts indefinitely, bugs technically don't exist as the program does what it's been programmed to do.

I only want this to be handled appropriately, that's all. The amount of bugs I encounter in software daily drives me crazy and the software quality is not as good as it used to be ten years ago.

Also, every issue I've had with immich makes immich unusable. I wouldn't recommend immich even to my worst enemy given the current state.

@szmarczak commented on GitHub (Sep 15, 2024): Feature request = adds new functionality. Bug report = fixes something that works incorrectly. Fixing a bug often requires adding new code, and new code does not necessarily mean new features. The functionality here is: uploading. Therefore no new functionality is added. You are fixing something that already exists. Look at it this way: you're playing a game that needs days to be completed. You have made some progress, you minimize the game, reopen it, and the entire progress is gone. No person would consider this ever as a missing feature because state preservation is expected. This is a bug. Even in universities missing state preservation (in context of mobile applications) is considered a bug and not a missing feature. So I'm surprised immich thinks otherwise. If you switched tabs in a browser and the form you just completed would reset... it's a bug, not a feature. The end user need not know the inner workings. The functionality is simple: upload, download, organize. If you were to split the functionality into smaller and smaller parts indefinitely, bugs technically don't exist as the program does what it's been programmed to do. I only want this to be handled appropriately, that's all. The amount of bugs I encounter in software daily drives me crazy and the software quality is not as good as it used to be ten years ago. Also, every issue I've had with immich makes immich unusable. I wouldn't recommend immich even to my worst enemy given the current state.

deekerman commented

2026-02-20 02:17:54 -05:00

Author

Owner

@alextran1502 commented on GitHub (Sep 15, 2024):

Sounds good, reopen it so we can track

@alextran1502 commented on GitHub (Sep 15, 2024): Sounds good, reopen it so we can track

deekerman commented

2026-02-20 02:17:54 -05:00

Author

Owner

@bo0tzz commented on GitHub (Sep 16, 2024):

I mean, regardless of all that this is effectively a duplicate of #2567/#1674

@bo0tzz commented on GitHub (Sep 16, 2024): I mean, regardless of all that this is effectively a duplicate of #2567/#1674

deekerman commented

2026-02-20 02:17:54 -05:00

Author

Owner

@szmarczak commented on GitHub (Sep 16, 2024):

@bo0tzz This is not a duplicate of #1674 because it's about a specific solution which solves many other problems, not just this one. My issue is about upload resetting. The solution is up to debate. How you deal with it is an internal detail, which I, as an end user, don't care about.

I only want backup to not reset. I have no idea why you'd want backups on the foreground task at all. Anyway, if you want backups on the foreground task, the background task could still continue for the last file, and new files to be backed up on the foreground task. I think that's the easiest solution. (Also, partial uploads don't require hashing, for a primitive solution you could just send to the server information the range in bytes in an HTTP header - Content-Range AFAIK, when reconnected it would just resume with the last successful range; this requires no changes to the server, only the mobile app, or very little if the server does not recognize the header).

This could be a duplicate of #2567, however the issue is about general refactor, which I'm not talking about. I'd prefer if the issue remained open.

@szmarczak commented on GitHub (Sep 16, 2024): @bo0tzz This is not a duplicate of #1674 because it's about a specific solution which solves many other problems, not just this one. My issue is about upload resetting. The solution is up to debate. How you deal with it is an internal detail, which I, as an end user, don't care about. I only want backup to not reset. I have no idea why you'd want backups on the foreground task at all. Anyway, if you want backups on the foreground task, the background task could still continue for the last file, and new files to be backed up on the foreground task. I think that's the easiest solution. (Also, partial uploads don't require hashing, for a primitive solution you could just send to the server information the range in bytes in an HTTP header - Content-Range AFAIK, when reconnected it would just resume with the last successful range; this requires no changes to the server, only the mobile app, or very little if the server does not recognize the header). This could be a duplicate of #2567, however the issue is about general refactor, which I'm not talking about. I'd prefer if the issue remained open.

deekerman commented

2026-02-20 02:17:55 -05:00

Author

Owner

@bo0tzz commented on GitHub (Sep 16, 2024):

Ultimately this will be solved by (either of) those other issues and will probably not be solved in another way. Keeping open a separate issue for every single angle of a thing doesn't make sense and would result in dozens of basically-duplicate issues, for the way we track things it's more appropriate to do it the way I have now. Whether you care about the "implementation details" of the solution doesn't really factor in to that.

@bo0tzz commented on GitHub (Sep 16, 2024): Ultimately this will be solved by (either of) those other issues and will probably not be solved in another way. Keeping open a separate issue for every single angle of a thing doesn't make sense and would result in dozens of basically-duplicate issues, for the way we track things it's more appropriate to do it the way I have now. Whether you care about the "implementation details" of the solution doesn't really factor in to that.

deekerman commented

2026-02-20 02:17:55 -05:00

Author

Owner

@szmarczak commented on GitHub (Sep 16, 2024):

will probably not be solved in another way

Let's set something straight. You do not know the future. It may or not may be. Talk about it once it's finished.

Keeping open a separate issue for every single angle of a thing doesn't make sense and would result in dozens of basically-duplicate issues

And again you're just straight plain wrong. Yes, you do keep track of every single piece that does not work, because:
a) the suggested solution once finished may not fix actually the issue - needs verification,
b) the suggested solution may be rejected, and once that issue is closed you lose track of all the pieces that were meant to be fixed.

it's more appropriate to do it the way I have now

No, it's exactly the reason that leads to situation like this where immich becomes unusuable. The more you think the solution will fix bunch of other ones, the more you enter into technical debt and the software in result is held by loose screws.

@szmarczak commented on GitHub (Sep 16, 2024): > will probably not be solved in another way Let's set something straight. You do not know the future. It may or not may be. Talk about it once it's finished. > Keeping open a separate issue for every single angle of a thing doesn't make sense and would result in dozens of basically-duplicate issues And again you're just straight plain wrong. Yes, you **do keep track of every single piece that does not work**, because: a) the suggested solution once finished may not fix actually the issue - needs verification, b) the suggested solution may be rejected, and once that issue is closed you lose track of all the pieces that were meant to be fixed. > it's more appropriate to do it the way I have now No, it's exactly the reason that leads to situation like this where immich becomes unusuable. The more you *think* the solution will fix bunch of other ones, the more you enter into technical debt and the software in result is held by loose screws.

Rows
Columns

Navigating away and back to Backup view resets upload #3869

The bug

The OS that Immich Server is running on

Version of Immich Server

Version of Immich Mobile App

Platform with the issue

Your docker-compose.yml content

Your .env content

Reproduction steps

Relevant log output

Additional information