[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. 😊

[s-martin]

…. 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. 😊

in addition this would solve the problem, if you have old scanned photos you could set only the date (e.g. aunt Mary’s 70. birthday) and then give the scanned files ascending file names and it would be in the correct order.

[bozo247]

Hi I'm also looking for a feature similar to this but only for Album->Options.

TLDR: Display options for images in an Album by 'filename ascending/descending'.

In my case, I am dealing with scanned photos - some 15k+ - they don't have EXIF metadata.

The scanned photos are in a chronological order, they are from literal physical photo albums.

If the original photo has writing on the rear of it, it is scanned automatically, but then needs to be displayed in the correct order, so I have scanned photos for example like, 'photo001_a.jpg', 'photo002_b.jpg' where 'a' is the front and '_b' is the rear of the photo if it detects text on it.

With the current 'Oldest/Newset first' display options photos are not displayed in the original chronological order as their names, which is important to display the rear text of the image.

SO...in addition to 'Oldest/Newest first' display options it would also be good to have the options 'filename ascending/descending' order.

Many thanks.

[ektaroc]

Bumping this. When I import scanned film I will usually select multiple photos and use the Immich web UI to change the date to the date the photos were taken, but I do not care about time, so all the photos are then sorted randomly since the date and time match. I agree that filename would be a good tiebreaker in cases like this.

[nkrabben]

Tagging in another use case, I've found one of my early digital cameras only recorded hh:mm timestamps. So I can have IMG_9783 and IMG_9786 from the same minute, but their order will be different on every timeline.

[blink7]

Same here. Google Photos sorts by date -> file name, so it would be great to have the same sorting in Immich too.

[anaxonda]

Sorting by filename would be a nice improvement as a tiebreaker over current behavior.

Also would be very nice to allow CreateDate to act as tiebreaker to DateTimeOriginal (so would be able to have hierarchy of conditional tiebreaker for date/time) Running into this immich issue with tens of thousands of analog scans. Official spec suggests time scanned should be stored in DateTimeDigitized which is mapped to xmp:CreateDate

4.6.6.6.2.
DateTimeDigitized
A tag used to record the date and time when the image was stored as digital data. For DSC, the
DateTimeDigitized will have the same content as the DateTimeOriginal. For film scan, the date and time
when the film was scanned and stored as digital data are recorded for the DateTimeDigitized. The format is
"YYYY:MM:DD HH:MM:SS" with time shown in 24-hour format, and the date and time separated by one
blank character [20.H]. When the date and time are unknown, all the character spaces except colons (":")
should be filled with blank characters, or else the field should be filled with blank characters. The character
string length is 20 Bytes including NULL for termination. When the field is left blank, it is treated as
unknown.