immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-03-01 11:20:12 +03:00
Code Issues 783 Packages Projects Releases 12 Wiki Activity

Timeline dates are jumbled up after (re)scanning massive external library #5101

New Issue
Closed
opened 2026-02-05 11:08:34 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2026-02-05 11:08:34 +03:00
Owner
Copy Link

Originally created by @dinosmm on GitHub (Jan 8, 2025).

The bug

Immich Web shows the timeline with date headers jumbled up if I scan a massive external library all at once.
Scanning library in smaller chunks (one folder at a time) seems to work in that the timeline headings are in the correct order.

This affects both the Web and Android apps but in very different ways. Please see more detailed explanation below.

The OS that Immich Server is running on

Ubuntu 22.04

Version of Immich Server

1.124.0

Version of Immich Mobile App

1.124.0

Platform with the issue

  • Server
  • Web
  • Mobile

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 o>
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - /media/StorageBoxEnc-NC/dinosm/files/Photos:/usr/src/app/external
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false
    logging:
      driver: "journald"
      options:
        tag: "immich"

  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>
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl>
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:eaba718fecd1196d88533de7ba49bf903ad33664a92debb24660a922ecd9cac8
    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:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd64>
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the valu>
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: >-
        pg_isready --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" || exit 1;
        Chksum="$$(psql --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" --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-vari>

# The location where your uploaded files are stored
UPLOAD_LOCATION=/home/dinosm/media/StorageBoxPhotosEnc/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.wikipe>
TZ=Europe/London

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

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

Reproduction steps

  1. Restart server
  2. Immich comes online before external library storage
  3. Rescan external library

Relevant log output

Log is too long,

Additional information

I originally added a massive external library all at once. Immich scanned it and showed all images and metadata fine, but the dates were jumbled up in the timeline, e.g. it would start at today, then yesterday, then 5th December, then 18th December, and so on.

I thought I had fixed this by removing the library and re-adding it one folder at a time. Scanning went well and all dates that I could check were in the right order.

Today I had to restart my server. I had an issue with the storage so it didn't come online before the Immich containers started, so Immich didn't show any photos (but the database was intact). I went to settings and rescanned the external library. As the library was rescanned as a whole, now the dates are jumbled up again.

On the Android app, things are much worse. Photos from random dates appear on each date heading (for example the 7th January heading contains photos from November 2021, the 6th January heading from other months and years etc).

All metadata on my photos is correct, and on the web UI, Immich correctly identifies it and places photos in the correct entry in the timeline.
On the Android app, again Immich reports the correct metadata date if I go into the photo details, but here it puts the photo under the wrong date heading and the headings are in the correct order (while on the web, all photos are shown under the correct date heading, and just the headings are jumbled up).

Originally created by @dinosmm on GitHub (Jan 8, 2025). ### The bug Immich Web shows the timeline with date headers jumbled up if I scan a massive external library all at once. Scanning library in smaller chunks (one folder at a time) seems to work in that the timeline headings are in the correct order. This affects both the Web and Android apps but in very different ways. Please see more detailed explanation below. ### The OS that Immich Server is running on Ubuntu 22.04 ### Version of Immich Server 1.124.0 ### Version of Immich Mobile App 1.124.0 ### Platform with the issue - [ ] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML 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 o> - ${UPLOAD_LOCATION}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro - /media/StorageBoxEnc-NC/dinosm/files/Photos:/usr/src/app/external env_file: - .env ports: - '2283:2283' depends_on: - redis - database restart: always healthcheck: disable: false logging: driver: "journald" options: tag: "immich" 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> # file: hwaccel.ml.yml # service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl> volumes: - model-cache:/cache env_file: - .env restart: always healthcheck: disable: false redis: container_name: immich_redis image: docker.io/redis:6.2-alpine@sha256:eaba718fecd1196d88533de7ba49bf903ad33664a92debb24660a922ecd9cac8 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:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd64> environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' volumes: # Do not edit the next line. If you want to change the database storage location on your system, edit the valu> - ${DB_DATA_LOCATION}:/var/lib/postgresql/data healthcheck: test: >- pg_isready --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" || exit 1; Chksum="$$(psql --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" --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-vari> # The location where your uploaded files are stored UPLOAD_LOCATION=/home/dinosm/media/StorageBoxPhotosEnc/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.wikipe> TZ=Europe/London # 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=password # The values below this line do not need to be changed ################################################################################### DB_USERNAME=postgres DB_DATABASE_NAME=immich ``` ### Reproduction steps 1. Restart server 2. Immich comes online before external library storage 3. Rescan external library ### Relevant log output ```shell Log is too long, ``` ### Additional information I originally added a massive external library all at once. Immich scanned it and showed all images and metadata fine, but the dates were jumbled up in the timeline, e.g. it would start at today, then yesterday, then 5th December, then 18th December, and so on. I thought I had fixed this by removing the library and re-adding it one folder at a time. Scanning went well and all dates that I could check were in the right order. Today I had to restart my server. I had an issue with the storage so it didn't come online before the Immich containers started, so Immich didn't show any photos (but the database was intact). I went to settings and rescanned the external library. As the library was rescanned as a whole, now the dates are jumbled up again. On the Android app, things are much worse. Photos from random dates appear on each date heading (for example the 7th January heading contains photos from November 2021, the 6th January heading from other months and years etc). All metadata on my photos is correct, and on the web UI, Immich correctly identifies it and places photos in the correct entry in the timeline. On the Android app, again Immich reports the correct metadata date if I go into the photo details, but here it puts the photo under the wrong date heading and the headings are in the correct order (while on the web, all photos are shown under the correct date heading, and just the headings are jumbled up).
OVERLORD added the date-time label 2026-02-05 11:08:34 +03:00
OVERLORD commented 2026-02-05 11:08:37 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Jan 8, 2025):

Tracking in #14824

@bo0tzz commented on GitHub (Jan 8, 2025): Tracking in #14824
OVERLORD commented 2026-02-05 11:08:39 +03:00
Author
Owner
Copy Link

@dinosmm commented on GitHub (Jan 8, 2025):

Sorry but this is not the same as #14824. In my case, Immich is not looking at the wrong EXIF date. It's taking the correct metadata and putting it under the correct date heading. It's the date headings within the Web UI that are jumbled up themselves.
EDIT: Unless there is something I understand very, very wrongly.

@dinosmm commented on GitHub (Jan 8, 2025): Sorry but this is not the same as #14824. In my case, Immich is not looking at the wrong EXIF date. It's taking the correct metadata and putting it under the correct date heading. It's the date headings within the Web UI that are jumbled up themselves. EDIT: Unless there is something I understand very, very wrongly.
OVERLORD commented 2026-02-05 11:08:40 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Jan 25, 2025):

In order to fix (and understand) this, I'd like to do small steps, i.e. concentrate on one issue first before tackling the other. For the web issue, I understand that the order of dates shown is wrong, but the photos shown for each such date are correct. Is that correct so far?

@C-Otto commented on GitHub (Jan 25, 2025): In order to fix (and understand) this, I'd like to do small steps, i.e. concentrate on one issue first before tackling the other. For the web issue, I understand that the order of dates shown is wrong, but the photos shown for each such date are correct. Is that correct so far?
OVERLORD commented 2026-02-05 11:08:41 +03:00
Author
Owner
Copy Link

@dinosmm commented on GitHub (Jan 25, 2025):

Yes that is correct.

@dinosmm commented on GitHub (Jan 25, 2025): Yes that is correct.
OVERLORD commented 2026-02-05 11:08:42 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Jan 25, 2025):

The date you see in the timeline is derived from the asset's localDateTime property, whereas the detail pane shows the exif.dateTimeOriginal (if that exists). As such, we might have two different dates.

For timeline sections which are in the wrong order, do the corresponding assets have the correct date (the one shown in the timeline)? Does the Android app show the same date when you view the details (swipe up)?

@C-Otto commented on GitHub (Jan 25, 2025): The date you see in the timeline is derived from the asset's `localDateTime` property, whereas the detail pane shows the `exif.dateTimeOriginal` (if that exists). As such, we might have two different dates. For timeline sections which are in the wrong order, do the corresponding assets have the correct date (the one shown in the timeline)? Does the Android app show the same date when you view the details (swipe up)?
OVERLORD commented 2026-02-05 11:08:43 +03:00
Author
Owner
Copy Link

@dinosmm commented on GitHub (Jan 25, 2025):

Every asset has the same date as the timeline section it is in.
If I remember correctly, the Android app had the same issue, but I can't remember if it showed the same incorrect order of timeline sections or a different incorrect order.

To clarify, I have since removed the external library and re-added it one folder at a time. I keep adding folders and the issue has not reappeared.
It only happened when I added my large external library all at once (on two separate occasions).

So for answering questions now, I go by what I remember. If you need me to do any further testing, I can do so by spinning up another instance (I don't want to mess up my primary one any more), do let me know.

@dinosmm commented on GitHub (Jan 25, 2025): Every asset has the same date as the timeline section it is in. If I remember correctly, the Android app had the same issue, but I can't remember if it showed the same incorrect order of timeline sections or a different incorrect order. To clarify, I have since removed the external library and re-added it one folder at a time. I keep adding folders and the issue has not reappeared. It only happened when I added my large external library all at once (on two separate occasions). So for answering questions now, I go by what I remember. If you need me to do any further testing, I can do so by spinning up another instance (I don't want to mess up my primary one any more), do let me know.
OVERLORD commented 2026-02-05 11:08:44 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Jan 25, 2025):

That be great, yes - especially if you can run database queries. Currently I have no idea what might be wrong.

@C-Otto commented on GitHub (Jan 25, 2025): That be great, yes - especially if you can run database queries. Currently I have no idea what might be wrong.
OVERLORD commented 2026-02-05 11:08:45 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Jan 25, 2025):

Please continue in #15640.

@C-Otto commented on GitHub (Jan 25, 2025): Please continue in #15640.
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 date-time
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#5101
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?