[Feature] Sort by date then filename for images taken at the same time

[bverkron]

The bug

Photos shot within the same second are next to each other in the Photos view but out of order amongst each other.

For example I have the following sequence of 10+ photos all shot in the same second on my Canon R6 MK II...
BV_20241106_8223
BV_20241106_8224
BV_20241106_8225
...
BV_20241106_8233
BV_20241106_8234
BV_20241106_8235

Under Photos in Immich they display in the following order. Doesn't matter if it's sorted newest to oldest or vice versa...

BV_20241106_8233
BV_20241106_8234
BV_20241106_8228
BV_20241106_8225
BV_20241106_8227
BV_20241106_8223
BV_20241106_8226
BV_20241106_8224
etc

I assume this is because they are all shot within the same second but images only sort based on timestamp and not a second metadata field such as name and thus anything shot in the same second ends up in a different (random?) order.

I would expect them to be sorted by time and then by filename or something else that would put them the correct sequence if they are all shot within the same second. Having them in a random order breaks the sequence flow for things like sports, etc.

The OS that Immich Server is running on

Ubuntu

Version of Immich Server

v1.120.2

Version of Immich Mobile App

n/a

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}
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
      - /media/ext_storage/photos/:/media/ext_storage/photos/: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/redis:6.2-alpine@sha256:2d1463258f2764328496376f5d965f20c6a67f66ea2b06dc42af351f75248792
    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:
      # 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
    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: null
networks: {}

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=/media/ext_storage/photos/immich/
# 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=America/Vancouver

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

...

Reproduction steps

1. Upload a series of images taken within the same second (for example in burst mode on a DSLR or presumably smartphone). I uploaded via the LR plugin but I assume the same behaviour will happen with photos uploaded via traditional methods.
2. View the photos in the Photos section of web or mobile app
3. The photos will not be in chronological order entirely. Photos from the same second are grouped together but in a mixed order in relation to each other.

Relevant log output

No response

Additional information

No response

[mertalev]

Timestamps should be sorted with millisecond precision. Can you check the EXIF data for these assets to see if the relevant date-time field (like DateTimeOriginal) is the same for these burst photos?

[bo0tzz]

Also check for ordering tags like SubSecTime

[bverkron]

Timestamps should be sorted with millisecond precision. Can you check the EXIF data for these assets to see if the relevant date-time field (like DateTimeOriginal) is the same for these burst photos?

If I'm reading the exiftools output correctly the original raw file (.cr3) has millisecond precision on the last 3 fields in the output (output grep'd for 'Date')

File Modification Date/Time     : 2024:11:06 10:52:37-08:00
File Access Date/Time           : 2024:11:07 08:02:03-08:00
File Inode Change Date/Time     : 2024:11:07 08:01:32-08:00
Date/Time Original              : 2024:11:06 14:52:37
Create Date                     : 2024:11:06 13:52:37-08:00
Modify Date                     : 2024:11:06 13:52:37-08:00
Track Create Date               : 2024:11:06 13:52:37-08:00
Track Modify Date               : 2024:11:06 13:52:37-08:00
Media Create Date               : 2024:11:06 13:52:37-08:00
Media Modify Date               : 2024:11:06 13:52:37-08:00
Create Date                     : 2024:11:06 14:52:37.57-07:00
Date/Time Original              : 2024:11:06 14:52:37.57-07:00
Modify Date                     : 2024:11:06 14:52:37.57-07:00

Whereas the image downloaded from Immich only has it in the Create Date field?

File Modification Date/Time     : 2024:11:18 09:15:48-08:00
File Access Date/Time           : 2024:11:18 09:24:25-08:00
File Inode Change Date/Time     : 2024:11:18 09:15:52-08:00
Modify Date                     : 2024:11:17 18:30:42
Date/Time Original              : 2024:11:06 17:52:37
Create Date                     : 2024:11:06 14:52:37
Digital Creation Date           : 2024:11:06
Profile Date Time               : 1998:02:09 06:49:00
Metadata Date                   : 2024:11:17 18:30:42-08:00
Date Created                    : 2024:11:06 17:52:37-07:00
Create Date                     : 2024:11:06 14:52:37.57-07:00
Date/Time Original              : 2024:11:06 17:52:37-07:00
Modify Date                     : 2024:11:17 18:30:42-08:00
Date/Time Created               : 2024:11:06 17:52:37-07:00
Digital Creation Date/Time      : 2024:11:06 14:52:37-07:00

I think that's a Lightroom issue (rather than an issue with the plugin). Even when I do a regular export from LR to my local disk it has the same metadata as what's in Immich, i.e. only has millisecond precision on the Create Date field :/

File Modification Date/Time     : 2024:11:18 09:35:28-08:00
File Access Date/Time           : 2024:11:18 09:35:32-08:00
File Inode Change Date/Time     : 2024:11:18 09:35:28-08:00
Modify Date                     : 2024:11:18 09:35:28
Date/Time Original              : 2024:11:06 17:52:37
Create Date                     : 2024:11:06 14:52:37
Digital Creation Date           : 2024:11:06
Profile Date Time               : 1998:02:09 06:49:00
Metadata Date                   : 2024:11:18 09:35:28-08:00
Date Created                    : 2024:11:06 17:52:37-07:00
Create Date                     : 2024:11:06 14:52:37.57-07:00
Date/Time Original              : 2024:11:06 17:52:37-07:00
Modify Date                     : 2024:11:18 09:35:28-08:00
Date/Time Created               : 2024:11:06 17:52:37-07:00
Digital Creation Date/Time      : 2024:11:06 14:52:37-07:00

So while this does not seem to be an Immich issue (my apologies) I wonder what the best way to handle this is since I cannot control what Lightroom exports (it's already set to export 'All Metadata').

I don't think Immich could reliably use the Create Date in this scenario because the photos have had their timestamp adjusted in LR to correct for a different timezone so if Immich fell back to something like Create Date if Date/Time Original (or whatever other field it looks at) does not have milliseconds it would put it out of order.

I wonder if falling back to image name would make sense since most of the time cameras and smartphones put their filenames in sequence and that would work as a proxy for time order? 🤔

[mertalev]

It should be fine to sort additionally by file name as a tie-breaker to handle this sort of thing.

[sietzebakker]

Milliseconds is not enough. Because when scanning a whole series of photos and then backdating them to the period in the past, all pictures get the same time. The trick is to sort by date + name of the file. Can be standard. Because that doesn't bother anyone I think. Actually only has advantages. 😊