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

Metadata extraction fails for files in External Libraries #8285

New Issue
Open
opened 2026-02-05 13:38:30 +03:00 by OVERLORD · 3 comments
OVERLORD commented 2026-02-05 13:38:30 +03:00
Owner
Copy Link

Originally created by @haoenz on GitHub (Jan 21, 2026).

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

  • Yes

The bug

My instance exclusively uses External Libraries. Occasionally, metadata is not extracted correctly for some files. This issue predominantly affects .mp4 video files. I have verified that the source files are not corrupted. Running exiftool on these files directly via the command line shows that the metadata exists and is readable.

I have attempted to resolve this by manually triggering the Extract metadata job in the Administration -> Job Queues section (attempting both "All" and "Missing"), but this does not solve the problem. The metadata remains missing.

However, if I navigate to the specific file's detail page and manually select Refresh metadata, the metadata is immediately and correctly extracted.

The OS that Immich Server is running on

Linux Mint 22.2

Version of Immich Server

2.4.1

Version of Immich Mobile App

n/a

Platform with the issue

  • Server
  • Web
  • Mobile

Device make and model

No response

Your docker-compose.yml content

#
# 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
      - /etc/localtime:/etc/localtime:ro
      - /media/username/m200:/mnt/m200
    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, 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:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571
    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:41eacbe83eca995561fe43814fd4891e16e39632806253848efaf04d3c8a8b84
    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:

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=Asia/Shanghai

# 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=my_db_password

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

Reproduction steps

I have not yet determined the exact trigger or pattern for this behavior, as it seems sporadic. I will update this issue if I discover a consistent reproduction method.

Relevant log output

Additional information

No response

Originally created by @haoenz on GitHub (Jan 21, 2026). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug My instance exclusively uses External Libraries. Occasionally, metadata is not extracted correctly for some files. This issue predominantly affects `.mp4` video files. I have verified that the source files are not corrupted. Running `exiftool` on these files directly via the command line shows that the metadata exists and is readable. I have attempted to resolve this by manually triggering the Extract metadata job in the `Administration -> Job Queues` section (attempting both "All" and "Missing"), but this does not solve the problem. The metadata remains missing. However, if I navigate to the specific file's detail page and manually select `Refresh metadata`, the metadata is immediately and correctly extracted. ### The OS that Immich Server is running on Linux Mint 22.2 ### Version of Immich Server 2.4.1 ### Version of Immich Mobile App n/a ### Platform with the issue - [x] Server - [x] Web - [ ] Mobile ### Device make and model _No response_ ### Your docker-compose.yml content ```YAML # # 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 - /etc/localtime:/etc/localtime:ro - /media/username/m200:/mnt/m200 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, 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: - .env restart: always healthcheck: disable: false redis: container_name: immich_redis image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571 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:41eacbe83eca995561fe43814fd4891e16e39632806253848efaf04d3c8a8b84 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: ``` ### 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=Asia/Shanghai # 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=my_db_password # The values below this line do not need to be changed ################################################################################### DB_USERNAME=postgres DB_DATABASE_NAME=immich_postgres ``` ### Reproduction steps I have not yet determined the exact trigger or pattern for this behavior, as it seems sporadic. I will update this issue if I discover a consistent reproduction method. ### Relevant log output ```shell ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 13:38:31 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Jan 21, 2026):

I can't find it right now, but I'm pretty sure there's an issue about this already.

@bo0tzz commented on GitHub (Jan 21, 2026): I can't find it right now, but I'm pretty sure there's an issue about this already.
OVERLORD commented 2026-02-05 13:38:33 +03:00
Author
Owner
Copy Link

@haoenz commented on GitHub (Jan 21, 2026):

I can't find it right now, but I'm pretty sure there's an issue about this already.

I assume you might be referring to #24805?

I tried multi-selecting files to refresh metadata as suggested, but it still failed. It only worked when refreshing files one by one. (Perhaps lowering concurrency to 1 would help? I can't test this now as I have no failing files left.)

Also, I see the manual fix as just a workaround. If I hadn't noticed a recent failure, I would have assumed "Extract Metadata All" was working, while many old files were actually failing silently.

As the OP of #24805 noted, there should be error logs for these failures, so I'm unsure why that issue was closed.

@haoenz commented on GitHub (Jan 21, 2026): > I can't find it right now, but I'm pretty sure there's an issue about this already. I assume you might be referring to #24805? I tried multi-selecting files to refresh metadata as suggested, but it still failed. It only worked when refreshing files one by one. (Perhaps lowering concurrency to 1 would help? I can't test this now as I have no failing files left.) Also, I see the manual fix as just a workaround. If I hadn't noticed a recent failure, I would have assumed "Extract Metadata All" was working, while many old files were actually failing silently. As the OP of #24805 noted, there should be error logs for these failures, so I'm unsure why that issue was closed.
OVERLORD commented 2026-02-05 13:38:34 +03:00
Author
Owner
Copy Link

@haoenz commented on GitHub (Jan 21, 2026):

I can't find it right now, but I'm pretty sure there's an issue about this already.

Also, I see the manual fix as just a workaround. If I hadn't noticed a recent failure, I would have assumed "Extract Metadata All" was working, while many old files were actually failing silently.

I only found these failures because I ensure all files have GPS, Make, and Model data before import, allowing me to filter for "Unknown" to spot them.

Users without such strict pre-processing wouldn't be able to distinguish extraction failures from files genuinely missing metadata.

This also concerns me regarding other jobs. For instance, I suspect Face Detection might also be failing silently for some files, but unlike metadata, I have no way to verify or filter for that.

@haoenz commented on GitHub (Jan 21, 2026): > > I can't find it right now, but I'm pretty sure there's an issue about this already. > > Also, I see the manual fix as just a workaround. If I hadn't noticed a recent failure, I would have assumed "Extract Metadata All" was working, while many old files were actually failing silently. I only found these failures because I ensure all files have GPS, Make, and Model data before import, allowing me to filter for "Unknown" to spot them. Users without such strict pre-processing wouldn't be able to distinguish extraction failures from files genuinely missing metadata. This also concerns me regarding other jobs. For instance, I suspect Face Detection might also be failing silently for some files, but unlike metadata, I have no way to verify or filter for that.
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#8285
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?