Failed to hash asset - Asset not found in library

[mpbzh]

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

• Yes

The bug

Since updating to the beta timeline I my sync is not working properly anymore. It never hashed all assets and I get lots of errors like the one posted below.

After each recent release I have tried a combination of the following steps:

• Logging out and back in
• Clearing the file cache
• Resetting the SQLite Database
• Deleting and reinstalling the app

None of these steps resolved the issue, I still have a never ending hashing job (currently at 15972 of 61525 assets, not increasing).

Syncing does not work properly (ready for upload are 0) and the list of remainders is very high

iCloud Photos is enabled and "Optimize Storage" is enabled (meaning Immich needs to download them for hashing and syncing).

I looked at some similar tickets (notably #22407, #22248, #20899, #21022) but none of them seem to be the exact same issue.

Let me know if you need any further information or tests to investigate the issue.

The OS that Immich Server is running on

Ubuntu 24.10

Version of Immich Server

v2.0.0

Version of Immich Mobile App

v2.0.0 build.229

Platform with the issue

• Server
• Web
• Mobile

Device make and model

iPhone 16 Pro - iOS 26

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
      - /mnt/mpb-filer/Media/Photos/Renders:/home/user/ext/renders:ro
      - /mnt/mpb-filer/Media/Photos/Years:/home/user/ext/years:ro
      - /mnt/mpb-filer/Media/Photos/Topics:/home/user/ext/topics:r
      - /mnt/mpb-filer/Media/Photos/Import:/home/user/ext/import:ro
      - /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/valkey/valkey:8-bookworm@sha256:ff21bc0f8194dc9c105b769aeabf9585fea6a8ed649c0781caeac5cb3c247884
    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'
      # Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs
      # DB_STORAGE_TYPE: 'HDD'
    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

  immich-public-proxy:
    image: alangrainger/immich-public-proxy:latest
    container_name: immich-public-proxy
    restart: always
    ports:
      - "3003:3000"
    environment:
      - IMMICH_URL=http://immich_server:2283
    healthcheck:
      test: curl -s http://localhost:3003/share/healthcheck -o /dev/null || exit 1
      start_period: 10s
      timeout: 5s
    depends_on:
      - immich-server

volumes:
  model-cache:

Your .env content

UPLOAD_LOCATION=/mnt/mpb-filer/Media/Photos/Immich
DB_DATA_LOCATION=/srv/docker/immich/postgres
TZ=Europe/Zurich
IMMICH_VERSION=release
DB_PASSWORD=postgres
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

1. Enable Sync
2. Wait for assets to be synced

Relevant log output

Entries like this:

Failed to hash asset with id: E5D09705-01C3-4B5B-83FE-54654ADC5347/L0/001, name: D0BB77BE-3E5F-49B6-B9A2-D9D933717C22.JPG, createdAt: 2016-12-01 12:07:12.000Z, from album: Album Name. Error: Asset not found in library

And entries like this:

Failed to hash asset with id: 3DB65B0D-A958-433E-8DB3-E6BDFA90405B/L0/001, name: IMG_0418.JPG, createdAt: 2020-06-19 16:41:10.000Z, from album: Album Name. Error: Failed to hash asset: Der Vorgang konnte nicht abgeschlossen werden. (PHPhotosErrorDomain-Fehler 3169.)

Additional information

No response

[shenlong-tanwen]

@mpbzh The 3169 error code means iOS has trouble fetching the asset from iCloud. Can you track the asset using the name, album name or the created at values from the log entries. They'd most likely are to be from a shared album. I'd suggest to first ignore the shared albums from the backup list, and start with a very small album first.

As for the Asset not found in library error, I suspect these are assets on the device trash. Need some additional troubleshooting to confirm as to why they're included in the local DB because they shouldn't be part of the local sync process. Can you check if you can find them there and let me know?

[mpbzh]

@shenlong-tanwen Thanks for the super quick response! I can confirm that all of the 3169 errors that I found on a very quick check are from shared albums. I have excluded all shared albums for now, but I hope that's an issue that can be resolved at some point.

As for the device trash: All the log entries that I found so far are from existing, non-shared albums. The one that I shared the log line for example, has been uploaded to immich previously (pre new timeline) and is still present in the album on my phone.

[shenlong-tanwen]

I have excluded all shared albums for now, but I hope that's an issue that can be resolved at some point.

We do have some plans to improve this, but we are mostly at the mercy of the OS to handle these properly and iOS in particular is giving us a lot of trouble :)

As for the device trash: All the log entries that I found so far are from existing, non-shared albums. The one that I shared the log line for example, has been uploaded to immich previously (pre new timeline) and is still present in the album on my phone.

Interesting, Let's first wait for the hashing to be completed. If there are new errors that are popping up, do share the logs and ping me here. Also, if you have optimize storage enabled and the assets are offloaded to iCloud, it might take some time for the app to download and hash them, which might make it seem like the hashing is stuck. I'd suggest giving it some time and it should eventually hash everything.

[mpbzh]

I once again tried to reset the SQLite database, log out, log back in and let it re-hash everything. So far it's at ~47k / 62k and still keeps growing.

I'll report back.

[mpbzh]

Update:

• The hashing job finished for the first time since the beta timeline 🥳. However it has only hashed 57787 of 61529 assets. Does it only hash assets that are not excluded?
• After excluding all shared albums, Immich successfully synced all other assets after only selecting the Recents album. Now I re-added all albums and assigned the assets using Backup Options ▸ Organize into albums. This generally worked, but a lot of Asset not found in library reappeared in the logs.

So generally, with these steps Immich finally went back from "not updating any photos" to "mostly working well, but having minor isssues". That's already good news!

How can I assist further in finding the root cause of the Asset not found in library errors?

[shenlong-tanwen]

• The hashing job finished for the first time since the beta timeline 🥳. However it has only hashed 57787 of 61529 assets. Does it only hash assets that are not excluded?

Yep, we hash assets only from the albums selected for backups. If the asset is part of only an excluded album, it will not be hashed. But if it is also part of a selected album, it should be hashed.

How can I assist further in finding the root cause of the Asset not found in library errors?

So these are actually the assets that we have found during local sync but cannot be obtained for hashing. This error is particularly weird because after a reinstall of the app, the local sync should pickup only those assets that are accessible. Can you use the log and see if you can find those assets on your library still? And make sure they are not hidden / trashed

[mpbzh]

Yep, we hash assets only from the albums selected for backups. If the asset is part of only an excluded album, it will not be hashed. But if it is also part of a selected album, it should be hashed.

That makes sense. So we can check off the hashing for now. What issue can I subscribe to for tracking the progress on shared albums?

So these are actually the assets that we have found during local sync but cannot be obtained for hashing. This error is particularly weird because after a reinstall of the app, the local sync should pickup only those assets that are accessible. Can you use the log and see if you can find those assets on your library still? And make sure they are not hidden / trashed

I made a couple of checks and can confirm that they are in a non-shared album and are downloaded from iCloud correctly when viewed in the photos app.

They do however appear to be duplicates from a mounted external share from the server side. But that should not affect local hashing on the phone, right?

[shenlong-tanwen]

That makes sense. So we can check off the hashing for now. What issue can I subscribe to for tracking the progress on shared albums?

I'm not sure if we have an issue that tracks this because this is actually an issue from iOS with how they server us the originals for uploads and not something that can be fixed from the app.

I made a couple of checks and can confirm that they are in a non-shared album and are downloaded from iCloud correctly when viewed in the photos app. They do however appear to be duplicates from a mounted external share from the server side. But that should not affect local hashing on the phone, right?

Yep, it doesn't matter that they're already on an external mount on the server. I can add additional logs in the next release and we can enable those and debug the "Asset not found in library" errors.