Indexierung von Immich bleibt hängen

shirocko

Cadet 3rd Year
Registriert
Juni 2012
Beiträge
37
Hallo zusammen,

ich habe etwas 168.000 Fotos und Videos auf meiner Synology Diskstation.
Bisher habe ich die integrierte Synology Photos App für die Anzeige von unterwegs verwendet, aber die App ist leider dermaßen langsam in der Anzeige. Man kann nicht mal eben jemandem ein Foto zeigen oder bestimmte Fotos suchen.

Und das Problem zu lösen möchte ich Immich verwenden.
Dazu habe ich auf meinem Proxmox Mini PC innerhalb einer Ubuntu VM Immich unter Docker aufgesetzt nach der offiziellen Anleitung.
Ich habe unter Ubuntu das Synology Photo Verzeichnis als CIFS Share read-only gemountet und es als read-only Laufwerk in Immich eingebunden.
Die Container laufen auch soweit ohne Fehler und die Indexierung läuft anfangs gut los und die ersten Vorschaubilder werden zügig erstellt. Nach einer Weile bleiben die Index Prozesse aber immer hängen und es passiert nichts mehr.
Man kann die Container neu starten und versuchen die Indexierung wieder neu anzustarten.
Dann werden auch Fotos gefunden, aber die Abarbeitung passiert nicht und die Warteschlange wird nicht leerer.
Die Anzeige sieht dann zum Beispiel so aus und es ändert nichts, auch nach Stunden
1762977957547.png

Man sieht auch, dass die CPU, RAM und Netzwerk quasi in Idle sind und es nichts passiert.
Ich habe den Stack bereits mehrfach weg geworfen und neu aufgesetzt und jedes Mal passiert das gleiche.
Nach einer Weile bleibt die Indexierung einfach hängen ohne Fehlermeldungen im Log.

Hier mein Portainer Stack
Code:
#
# WARNING: To install Immich, follow our guide: https://docs.immich.app/install/docker-compose
#
# 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:
  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}:/data
      - ${EXTERNAL_PHOTO_LOCATION}:/photo_syno_ro:ro
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - stack.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, rocm, openvino, rknn] 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://docs.immich.app/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - stack.env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:8@sha256:81db6d39e1bba3b3ff32bd3a1b19a6d69690f94a3954ec131277b9a26b95b3aa
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    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
    shm_size: 128mb
    restart: always

volumes:
  model-cache:

DIe stack.env Datei
Code:
UPLOAD_LOCATION=/mnt/dockerdata/immich/library
EXTERNAL_PHOTO_LOCATION=/mnt/photo_syno_readonly
DB_DATA_LOCATION=/mnt/dockerdata/immich/postgres
IMMICH_VERSION=v2
DB_PASSWORD=sicheresPasswort
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
TZ=Europe/Berlin
 
Hm, wieviel Ressourcen hat deine VM / Docker denn zur Verfügung?

Hatte noch keine Probleme mit 12Gb RAM und 8 Threads.

Läuft es denn irgendwie weiter, wenn du es neu startest oder gar nicht?
 
Sicher, dass das Standardwerte sind bzgl. Parallelisierung? Steht bei mir so:
1762985841110.png


Ansonsten habe ich eine ziemlich ähnliche config, nur auf einer Synology 224+ mit 18GB RAM.

Und ansonsten schon in die Doku geguckt? Gibt auf Github generell einiges an Doku und issues, in denen man nachlesen kann.

Troubleshooting​

Sometimes, an external library will not scan correctly. This can happen if Immich can't access the files. Here are some things to check:

  • In the docker-compose file, are the volumes mounted correctly?
  • Are the volumes also mounted to any worker containers?
  • Are the import paths set correctly, and do they match the path set in docker-compose file?
  • Make sure you don't use symlinks in your import libraries, and that you aren't linking across docker mounts.
  • Are the permissions set correctly?
  • Make sure you are using forward slashes (/) and not backward slashes.
To validate that Immich can reach your external library, start a shell inside the container. Run docker exec -it immich_server bash to a bash shell. If your import path is /mnt/photos, check it with ls /mnt/photos. If you are using a dedicated microservices container, make sure to add the same mount point and check for availability within the microservices container as well.
 
Zuletzt bearbeitet:
Hi zusammen,

danke zunächst für die Antworten.
Immich läuft in einer VM mit 4 Kernen und 12 GB RAM.

Ich habe die Instanz eines weiteres Mal aufgesetzt und dieses Mal die Anzahl der Prozess gering gehalten.
Besonders den für die Miniaturansichten habe ich nur auf 5 gesetzt, weil dort die CPU noch knapp unter 100% blieb.
Die Metadaten und Sidecar Metadaten Threads habeich zwischenzeitlich auch 10-15 erhöht, um die Abarbeitung zu beschleunigen.
Und tatsächlich ist jetzt nach einem Tag der erste Schwung Daten abgearbeitet.
Er hat allerdings nur 130.000 von 186.000 Fotos/Videos in der Bibliothek.
Ich habe den Scan nun erneut gestartet und jetzt werde noch einmal 66.000 Dateien indexiert.

Es scheint also wohl wirklich an der Anzahl der Prozesse gelegen zu haben.
Mich wundert es allerdings, dass nach einer Weile gar nichts mehr ging.
Selbst wo ich dann die Anzahl wieder auf 3-4 reduziert hatte, hat Immich einfach gar nichts mehr gemacht.
Es scheint so, dass wenn es einmal in diesen Stillstand rein gelaufen ist, dann hat man keine Möglichkeit mehr den Prozess wieder zu korrigieren.

Aktuell läuft es erst einmal. Die Fotos sind zwar zum Teil komisch in der Timeline einsortiert, aber danke vorerst für die Tipps.
 
Zurück
Oben