[BUG] Web client has major performance issues with large image library

[rcdailey]

The bug

Using Immich v1.79.1, I am observing the following issues:

1. Extremely long load times when viewing the main timeline view
2. A lot of stuttering/lag when scrolling vertically through the timeline

After installing using the docker-compose.yml provided in the installation docs, I introduced an external photo directory. Immich reports about 65,000 photos. I suspect the web client is trying to load information for all of these photos which would explain the symptoms. But I don't know for sure.

I have NOT uploaded any photos to Immich at this point. All I have done is added existing photos from a different mounted directory.

The OS that Immich Server is running on

Unraid (using docker compose)

Version of Immich Server

v1.79.1

Version of Immich Mobile App

N/A

Platform with the issue

• [ ] Server
• [X] Web
• [ ] Mobile

Your docker-compose.yml content

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "immich" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /mnt/user/photos/external:/mnt/media/external:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
      - typesense
    restart: always

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.yml
    #   service: hwaccel
    command: [ "start.sh", "microservices" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /mnt/user/photos/external:/mnt/media/external:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
      - typesense
    restart: always

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - ./model-cache:/cache
    env_file:
      - .env
    restart: always

  immich-web:
    container_name: immich_web
    image: ghcr.io/immich-app/immich-web:${IMMICH_VERSION:-release}
    env_file:
      - .env
    restart: always

  typesense:
    container_name: immich_typesense
    image: typesense/typesense:0.24.1@sha256:9bcff2b829f12074426ca044b56160ca9d777a0c488303469143dd9f8259d4dd
    environment:
      - TYPESENSE_API_KEY=${TYPESENSE_API_KEY}
      - TYPESENSE_DATA_DIR=/data
      # remove this to get debug messages
      - GLOG_minloglevel=1
    volumes:
      - ./tsdata:/data
    restart: always

  redis:
    container_name: immich_redis
    image: redis:6.2-alpine@sha256:70a7a5b641117670beae0d80658430853896b5ef269ccf00d1827427e3263fa3
    restart: always

  database:
    container_name: immich_postgres
    image: postgres:14-alpine@sha256:28407a9961e76f2d285dc6991e8e48893503cc3836a4755bbc2d40bcc272a441
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    restart: always

  immich-proxy:
    container_name: immich_proxy
    image: ghcr.io/immich-app/immich-proxy:${IMMICH_VERSION:-release}
    environment:
      # Make sure these values get passed through from the env file
      - IMMICH_SERVER_URL
      - IMMICH_WEB_URL
    ports:
      - 2283:8080
    depends_on:
      - immich-server
      - immich-web
    restart: always

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=/mnt/user/photos/immich

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

# Connection secrets for postgres and typesense. You should change these to random passwords
TYPESENSE_API_KEY=snip
DB_PASSWORD=snip

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

REDIS_HOSTNAME=immich_redis

Reproduction steps

Explained in description.

Tested using:
- Microsoft Edge on Windows 10
- Microsoft Edge on Macbook Pro 2023
- Firefox on Windows 10

All scenarios had similar or identical symptoms.

Additional information

No response

[jrasm91]

It definitely does not load everything for the main timeline. Can you record a video of what you are seeing? You can DM it to me on discord if needed.

[rcdailey]

I can't take a video in this case, there's just too many personal photos of mine that would be visible and I'm not comfortable sharing that. I don't know if it's helpful but I can show you this from the Networking tab of dev tools:

It clearly shows which requests are taking the longest

[alextran1502]

Can you click on that large request and get the request content body? Did you get the same issue on previous version?

My guess is that you have a very large collection in the month of Dec 2022, is that the correct observation?

[rcdailey]

The response was so big that the inspector evicted the data. I used Postman to send the request with an API Key and the total size of the JSON data returned is 60MB!

I can't even pretty format it in VS Code without causing it to crash.

How can this not be the whole library of 65k images?

[rcdailey]

My guess is that you have a very large collection in the month of Dec 2022, is that the correct observation?

Based on the little timeline view on the right side, November 2022 appears to be very large. I don't know why the photos are all grouped under that 1 month but I think that's wrong. Maybe the metadata in the image files is wrong.

[alextran1502]

When the page finally loaded, do you see all images are grouped under that one month?

[jrasm91]

There are two time bucket endpoints. One returns after details by month, that is the very large one you are seeing. The other one returns counts by month. Can you try to capture that one? It should be much smaller and have more details about the distribution of photos

[rcdailey]

There are two time bucket endpoints. One returns after details by month, that is the very large one you are seeing. The other one returns counts by month. Can you try to capture that one? It should be much smaller and have more details about the distribution of photos

[
    {
        "count": 52851,
        "timeBucket": "2022-12-01T00:00:00.000Z"
    },
    {
        "count": 397,
        "timeBucket": "2018-10-01T00:00:00.000Z"
    },
    {
        "count": 11,
        "timeBucket": "2016-10-01T00:00:00.000Z"
    },
    {
        "count": 62,
        "timeBucket": "2016-09-01T00:00:00.000Z"
    },
    {
        "count": 65,
        "timeBucket": "2016-08-01T00:00:00.000Z"
    },
    {
        "count": 68,
        "timeBucket": "2016-07-01T00:00:00.000Z"
    },
    {
        "count": 23,
        "timeBucket": "2016-06-01T00:00:00.000Z"
    },
    {
        "count": 41,
        "timeBucket": "2016-05-01T00:00:00.000Z"
    },
    {
        "count": 40,
        "timeBucket": "2016-04-01T00:00:00.000Z"
    },
    {
        "count": 33,
        "timeBucket": "2016-03-01T00:00:00.000Z"
    },
    {
        "count": 172,
        "timeBucket": "2016-02-01T00:00:00.000Z"
    },
    {
        "count": 13,
        "timeBucket": "2016-01-01T00:00:00.000Z"
    },
    {
        "count": 569,
        "timeBucket": "2015-12-01T00:00:00.000Z"
    },
    {
        "count": 34,
        "timeBucket": "2015-11-01T00:00:00.000Z"
    },
    {
        "count": 30,
        "timeBucket": "2015-10-01T00:00:00.000Z"
    },
    {
        "count": 81,
        "timeBucket": "2015-09-01T00:00:00.000Z"
    },
    {
        "count": 117,
        "timeBucket": "2015-08-01T00:00:00.000Z"
    },
    {
        "count": 52,
        "timeBucket": "2015-07-01T00:00:00.000Z"
    },
    {
        "count": 12,
        "timeBucket": "2015-06-01T00:00:00.000Z"
    },
    {
        "count": 76,
        "timeBucket": "2015-05-01T00:00:00.000Z"
    },
    {
        "count": 254,
        "timeBucket": "2015-04-01T00:00:00.000Z"
    },
    {
        "count": 18,
        "timeBucket": "2015-03-01T00:00:00.000Z"
    },
    {
        "count": 26,
        "timeBucket": "2015-02-01T00:00:00.000Z"
    },
    {
        "count": 12,
        "timeBucket": "2014-12-01T00:00:00.000Z"
    },
    {
        "count": 6,
        "timeBucket": "2014-11-01T00:00:00.000Z"
    },
    {
        "count": 10,
        "timeBucket": "2014-10-01T00:00:00.000Z"
    },
    {
        "count": 4,
        "timeBucket": "2014-09-01T00:00:00.000Z"
    },
    {
        "count": 8,
        "timeBucket": "2014-07-01T00:00:00.000Z"
    },
    {
        "count": 4,
        "timeBucket": "2014-06-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2014-05-01T00:00:00.000Z"
    },
    {
        "count": 68,
        "timeBucket": "2014-04-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2014-03-01T00:00:00.000Z"
    },
    {
        "count": 58,
        "timeBucket": "2014-02-01T00:00:00.000Z"
    },
    {
        "count": 94,
        "timeBucket": "2014-01-01T00:00:00.000Z"
    },
    {
        "count": 990,
        "timeBucket": "2013-12-01T00:00:00.000Z"
    },
    {
        "count": 159,
        "timeBucket": "2013-11-01T00:00:00.000Z"
    },
    {
        "count": 183,
        "timeBucket": "2013-10-01T00:00:00.000Z"
    },
    {
        "count": 191,
        "timeBucket": "2013-09-01T00:00:00.000Z"
    },
    {
        "count": 283,
        "timeBucket": "2013-08-01T00:00:00.000Z"
    },
    {
        "count": 93,
        "timeBucket": "2013-07-01T00:00:00.000Z"
    },
    {
        "count": 15,
        "timeBucket": "2013-06-01T00:00:00.000Z"
    },
    {
        "count": 14,
        "timeBucket": "2013-05-01T00:00:00.000Z"
    },
    {
        "count": 164,
        "timeBucket": "2013-04-01T00:00:00.000Z"
    },
    {
        "count": 31,
        "timeBucket": "2013-03-01T00:00:00.000Z"
    },
    {
        "count": 80,
        "timeBucket": "2013-02-01T00:00:00.000Z"
    },
    {
        "count": 300,
        "timeBucket": "2013-01-01T00:00:00.000Z"
    },
    {
        "count": 410,
        "timeBucket": "2012-12-01T00:00:00.000Z"
    },
    {
        "count": 144,
        "timeBucket": "2012-11-01T00:00:00.000Z"
    },
    {
        "count": 48,
        "timeBucket": "2012-10-01T00:00:00.000Z"
    },
    {
        "count": 26,
        "timeBucket": "2012-09-01T00:00:00.000Z"
    },
    {
        "count": 48,
        "timeBucket": "2012-05-01T00:00:00.000Z"
    },
    {
        "count": 364,
        "timeBucket": "2012-04-01T00:00:00.000Z"
    },
    {
        "count": 736,
        "timeBucket": "2012-03-01T00:00:00.000Z"
    },
    {
        "count": 168,
        "timeBucket": "2012-02-01T00:00:00.000Z"
    },
    {
        "count": 6,
        "timeBucket": "2012-01-01T00:00:00.000Z"
    },
    {
        "count": 288,
        "timeBucket": "2011-12-01T00:00:00.000Z"
    },
    {
        "count": 116,
        "timeBucket": "2011-11-01T00:00:00.000Z"
    },
    {
        "count": 532,
        "timeBucket": "2011-10-01T00:00:00.000Z"
    },
    {
        "count": 12,
        "timeBucket": "2011-09-01T00:00:00.000Z"
    },
    {
        "count": 64,
        "timeBucket": "2011-08-01T00:00:00.000Z"
    },
    {
        "count": 148,
        "timeBucket": "2011-07-01T00:00:00.000Z"
    },
    {
        "count": 20,
        "timeBucket": "2011-06-01T00:00:00.000Z"
    },
    {
        "count": 12,
        "timeBucket": "2011-05-01T00:00:00.000Z"
    },
    {
        "count": 411,
        "timeBucket": "2011-04-01T00:00:00.000Z"
    },
    {
        "count": 230,
        "timeBucket": "2011-03-01T00:00:00.000Z"
    },
    {
        "count": 238,
        "timeBucket": "2011-02-01T00:00:00.000Z"
    },
    {
        "count": 41,
        "timeBucket": "2011-01-01T00:00:00.000Z"
    },
    {
        "count": 370,
        "timeBucket": "2010-12-01T00:00:00.000Z"
    },
    {
        "count": 142,
        "timeBucket": "2010-11-01T00:00:00.000Z"
    },
    {
        "count": 46,
        "timeBucket": "2010-10-01T00:00:00.000Z"
    },
    {
        "count": 12,
        "timeBucket": "2010-09-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2010-08-01T00:00:00.000Z"
    },
    {
        "count": 6,
        "timeBucket": "2010-06-01T00:00:00.000Z"
    },
    {
        "count": 586,
        "timeBucket": "2010-05-01T00:00:00.000Z"
    },
    {
        "count": 4,
        "timeBucket": "2010-04-01T00:00:00.000Z"
    },
    {
        "count": 68,
        "timeBucket": "2010-03-01T00:00:00.000Z"
    },
    {
        "count": 22,
        "timeBucket": "2010-02-01T00:00:00.000Z"
    },
    {
        "count": 266,
        "timeBucket": "2010-01-01T00:00:00.000Z"
    },
    {
        "count": 114,
        "timeBucket": "2009-12-01T00:00:00.000Z"
    },
    {
        "count": 6,
        "timeBucket": "2009-10-01T00:00:00.000Z"
    },
    {
        "count": 130,
        "timeBucket": "2009-09-01T00:00:00.000Z"
    },
    {
        "count": 84,
        "timeBucket": "2009-08-01T00:00:00.000Z"
    },
    {
        "count": 84,
        "timeBucket": "2009-07-01T00:00:00.000Z"
    },
    {
        "count": 134,
        "timeBucket": "2009-05-01T00:00:00.000Z"
    },
    {
        "count": 144,
        "timeBucket": "2009-04-01T00:00:00.000Z"
    },
    {
        "count": 117,
        "timeBucket": "2009-03-01T00:00:00.000Z"
    },
    {
        "count": 320,
        "timeBucket": "2009-02-01T00:00:00.000Z"
    },
    {
        "count": 303,
        "timeBucket": "2009-01-01T00:00:00.000Z"
    },
    {
        "count": 164,
        "timeBucket": "2008-12-01T00:00:00.000Z"
    },
    {
        "count": 166,
        "timeBucket": "2008-11-01T00:00:00.000Z"
    },
    {
        "count": 16,
        "timeBucket": "2008-10-01T00:00:00.000Z"
    },
    {
        "count": 32,
        "timeBucket": "2008-09-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2008-07-01T00:00:00.000Z"
    },
    {
        "count": 216,
        "timeBucket": "2008-06-01T00:00:00.000Z"
    },
    {
        "count": 8,
        "timeBucket": "2008-05-01T00:00:00.000Z"
    },
    {
        "count": 20,
        "timeBucket": "2008-04-01T00:00:00.000Z"
    },
    {
        "count": 8,
        "timeBucket": "2008-02-01T00:00:00.000Z"
    },
    {
        "count": 14,
        "timeBucket": "2008-01-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2007-12-01T00:00:00.000Z"
    },
    {
        "count": 6,
        "timeBucket": "2007-11-01T00:00:00.000Z"
    },
    {
        "count": 24,
        "timeBucket": "2007-09-01T00:00:00.000Z"
    },
    {
        "count": 16,
        "timeBucket": "2007-07-01T00:00:00.000Z"
    },
    {
        "count": 12,
        "timeBucket": "2007-06-01T00:00:00.000Z"
    },
    {
        "count": 18,
        "timeBucket": "2007-05-01T00:00:00.000Z"
    },
    {
        "count": 26,
        "timeBucket": "2007-04-01T00:00:00.000Z"
    },
    {
        "count": 180,
        "timeBucket": "2007-01-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2006-12-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2006-09-01T00:00:00.000Z"
    },
    {
        "count": 2,
        "timeBucket": "2006-01-01T00:00:00.000Z"
    },
    {
        "count": 1,
        "timeBucket": "1969-12-01T00:00:00.000Z"
    }
]

[alextran1502]

I suspect this is related to #4191, which might fix this in the next release. When the next release is out, can you create a new instance and import the photos again?

[rcdailey]

I'd be more than happy to try this again. I appreciate everyone's attention to this!

[JosiahBull]

From my current understanding #4191 won't fix this issue? What if a user legitimately has several thousand photos on a single day, or even from a single hour?

A common instance I can think of is a user who copies a Gphotos library over without applying exif - all items will be on the same date. There's needs to be some item-count based batching instead of date-based batching to resolve this permanently.

[jrasm91]

Practically, it hasn't happened yet where somebody has so many photos that the segment by month strategy has failed, minus this case. It doesn't sound like the expected results are 50k photos either. For now, I am fine leaving the implementation as is and seeing if there is a legitimate use case for 5k+, 10k+, etc. photos in a single month by a single user.

[jrasm91]

As far as handling the specific situation where an import or similar causes this situation, I think it would be acceptable to detect the situation, truncate the results to some reasonable amount and show the user a warning about the situation. Ideally they can correct the exif and then continue to use the system as normal.

We've not designed it to work with this volume of photos and it would require quite a bit of work to change that. Unless there are some real life use cases for it I think we can leave it as is for now.

[curtwagner1984]

Practically, it hasn't happened yet where somebody has so many photos that the segment by month strategy has failed, minus this case. It doesn't sound like the expected results are 50k photos either. For now, I am fine leaving the implementation as is and seeing if there is a legitimate use case for 5k+, 10k+, etc. photos in a single month by a single user.

If you're a photographer and you take hundreds/thousands of pictures a day, it's more than feasible that you'll have that number of images per month.

Regardless of the use case, from my understanding, if the user has 5k images that are dated at the same month, the Web App will try to load all of those images? If that's true, then it seems it might be a design issue, regardless of the use case.

Perhaps the loaded images should be per amount of loaded images regardless of the month. And when you scroll down more images are loaded. (from the same month, if that particular month had a lot of images). This way, this issue will never occur, regardless of the amount of images per month.

It's unreasonable for the app to freeze if it encounters a month with a lot of photos. This makes the web app unusable for users who encountered this issue.

I'm also usure if it's feasible to fix the exif on 5k images, the dates of the photos might be unbailable or never recorded.

[jrasm91]

I think it's great that Immich even exists at all. I also think that it is OK, that it doesn't service every group of users out the gate. If you want to call that a "design issue", that's up to you.

The group of users it does service, it does so really well. Unfortunately, the 5k+ / month professional photographers isn't currently in that category. Fortunately, I have yet to hear of one that is running into this limitation in the first place.

Assets are grouped by month in part so that the virtual scrollbar has some semi-accurate spacing and the justified layout can be calculated for the time period. Neither of those features (justified layout or virtual scrollbar) can exist very easily when you shift to a "per amount" strategy.

There is also the possibility to explore loading statistics per day and load groups of photos per day. I don't know if anybody wants to work on this though. Priorities on an open source project are a bit different since people work on what is interesting to them and/or what issues current users are facing.

[rcdailey]

Practically, it hasn't happened yet where somebody has so many photos that the segment by month strategy has failed, minus this case. It doesn't sound like the expected results are 50k photos either. For now, I am fine leaving the implementation as is and seeing if there is a legitimate use case for 5k+, 10k+, etc. photos in a single month by a single user.

I want to clarify that the results are intended, or at least, not something I'm willing or able to fix. Most of these photos were scanned in IIRC, so the date information probably isn't right. In either case, fixing 65k images is out of the question for me.

it seems it might be a design issue, regardless of the use case [...] It's unreasonable for the app to freeze if it encounters a month with a lot of photos. This makes the web app unusable for users who encountered this issue. I'm also usure if it's feasible to fix the exif on 5k images, the dates of the photos might be unbailable or never recorded.

I agree with all of these points. It's unfortunate that I'm apparently a corner case here and because of that there's no apparent motivation to fix this. I was excited to use Immich but I'll apparently have to continue using Google Photos or find some other alternative that properly handles my situation.

[alextran1502]

I think we have option to group and fetch date bucket by date instead of by month, correct?

[jrasm91]

@rcdailey - we can certainly look into this if it is a blocker for you. I assumed, perhaps incorrectly that you would look into using exiftool or another solution to correct the dates for those images. Exiftool can bulk update metadata following a pattern.

[curtwagner1984]

I think it's great that Immich even exists at all. I also think that it is OK, that it doesn't service every group of users out the gate. If you want to call that a "design issue", that's up to you.

First and foremost, I'm genuinely appreciative of Immich's existence and the contributions everyone has made to it. I'm in complete agreement that it's okay for a software to not cater to every user group immediately. My mention of a "design issue" wasn't aimed at critiquing this aspect.

The core of my concern is the application's handling of unexpected volumes of input. If Immich is designed to handle, let's say, X images at once, encountering a scenario with more than X images should be managed gracefully. One possible solution could be limiting the image requests to X and providing a user with a message for the surplus (e.g., 5 images not loaded). This threshold, X, could perhaps even be user-configurable based on individual hardware capacities.

Addressing your point about assets being grouped by month for the virtual scrollbar and justified layout: might it be possible to simply deactivate the virtual scrollbar in situations where the image volume of a month necessitates batching? In my perspective, having Immich operate without the virtual scrollbar is far more preferable than having it hang to the point of tab closure.

Regarding loading images by day, I'm doubtful this will resolve the issue, as you pointed out, a large batch of images imported/uploaded without Exif data would be treated as coming from the same day.

To wrap up, I'd like to emphasize that my intention is never to belittle or discredit the effort that's gone into Immich. When highlighting what I see as a design challenge, it's purely from a constructive feedback standpoint and in no way a critique of the project's overall value or the dedication of its contributors.

[JosiahBull]

Similar to other comments in this thread I'm extremely excited about Immich existing, and appreciative of the work that's gone into it. It's refreshing to have such a professional FOSS solution to host and share my family photos.

That being said, I think it's possible for non-professional photographers to exceed the limits imposed by the current design, and I think Immich should be able to gracefully handle large photo uploads across a single month.

I took a team trip a couple of years ago and we had a shared album for photos, which accumulated ~1500 photos in only 3 days. I think it's extremely feasible for 'vanilla' users to have a month that crashes the app when they scroll past it if they went traveling with a group at some point.

Notably I had a botched Google Takeout export which failed to provide json data for ~15k images. I'm aware this is an upstream issue with Google, but for me all these images are stacked on a single day, and I don't have recourse to resolve it beyond manually tagging them... :/

[jrasm91]

@curtwagner1984 @JosiahBull - I think those are all valid points and the system should definitely handle those situations (better at least). We can look at improving this in the future for sure. Some ideas that have been brought up include:

• Truncating assets and showing an error message rather than crashing
• Seeing if loading assets by day extends the range/scale in a meaningful way
• Disabling the virtual scrollbar and using an alternative loading strategy for ranges with big groups

Thanks you for your feedback!

[lachlan2k]

Would it perhaps be viable to chunk the API requests, using some sort of offset-based pagination, for instance with optional limit and offset parameters? Such that the initial request would contain &limit=5000&offset=0 followed by &limit=5000&offset=5000, etc. until all the data has loaded.

[dodg3r]

Hi

This error is consistent with the problem I'm having. The difference is that my main timelineview freezes completely and I can't move forward. If I quickly click on "people" or "albums" or "explore" after logging in, I can scroll further, but as soon as I go back to the timeline, it freezes again. I have 140,000 pictures and 11,000 of them are from the year 2023-10. Could that be the problem?

Can I edit the files directly in the library folder with EXIF?

[curtwagner1984]

Yeah, this is definitely the same issue. For me the browser tab completely freezes and had to be killed. I have to navigate to the explore it people tab manually.

On Wed, Oct 25, 2023, 13:56 Jerry Johansson @.***> wrote:

Hi

This error is consistent with the problem I'm having. The difference is that my main timelineview freezes completely and I can't move forward. If I quickly click on "people" or "albums" or "explore" after logging in, I can scroll further, but as soon as I go back to the timeline, it freezes again. I have 140,000 pictures and 11,000 of them are from the year 2023-10. Could that be the problem?

Can I edit the files directly in the library folder with EXIF?

— Reply to this email directly, view it on GitHub https://github.com/immich-app/immich/issues/4180#issuecomment-1779009687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZFOUKKVEX6C3EBB27GPVLYBDV7FAVCNFSM6AAAAAA5DRAK3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZZGAYDSNRYG4 . You are receiving this because you were mentioned.Message ID: @.***>

[jrasm91]

I actually did some more research into this and I don't think it's actually a problem with loading that many assets at once, or sending that much data across the wire, it comes down to how granular of groups we use to render the assets in the web. We use an intersection observer, but it looks like it works at the per day level, so it will try to render all the assets for a given day as you are scrolling.

[curtwagner1984]

It would have been really, really, really, great if the user could override this to a specific count. Like, render at most 20 images as I'm scrolling.

On Thu, Oct 26, 2023 at 12:00 AM Jason Rasmussen @.***> wrote:

I actually did some more research into this and I don't think it's actually a problem with loading that many assets at once, or sending that much data across the wire, it comes down to how granular of groups we use to render the assets in the web. We use an intersection observer, but it looks like it works at the per day level, so it will try to render all the assets for a given day as you are scrolling.

— Reply to this email directly, view it on GitHub https://github.com/immich-app/immich/issues/4180#issuecomment-1780046372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZFOUKMQ62LGDLV2R7GEBTYBF4V7AVCNFSM6AAAAAA5DRAK3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGA2DMMZXGI . You are receiving this because you were mentioned.Message ID: @.***>

[alextran1502]

@curtwagner1984 it will be an optimization for this mechanism. We will find sometimes to work on this

[curtwagner1984]

Thank you for considering my request for this optimization. 🙏

On Thu, Oct 26, 2023, 18:43 Alex @.***> wrote:

@curtwagner1984 https://github.com/curtwagner1984 it will be an optimization for this mechanism. We will find sometimes to work on this

— Reply to this email directly, view it on GitHub https://github.com/immich-app/immich/issues/4180#issuecomment-1781381690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZFOUN5R6JT466M64YKU33YBKAKPAVCNFSM6AAAAAA5DRAK3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRGM4DCNRZGA . You are receiving this because you were mentioned.Message ID: @.***>

[peca89]

I'm also very much excited about Immich being actively developped. Since local library feature is introduced, I'm in the process of evaluating Immich's performance compared to Plex in order for it to become main picture archive viewer. I find myself quite bothered about existance of this bug/feature that I need to point out why this would be a dealbreaker for me unless it's fixed.

My personal library contains a folder with a bunch of scanned films where all files share the same date. Because for the most of films even the approximate date of capturing is unknown, I decided to batch set file and exif date for all these files to a random date in 1990. Anything else, like randomizing the date, would sort the pictures completely incorrectly. It's about 10000 photos (more than 200 films were scanned) that would show as if they were the same date.

[jrasm91]

It would have been really, really, really, great if the user could override this to a specific count. Like, render at most 20 images as I'm scrolling.

That doesn't really make sense IMO. Having specific settings like "how many images to load at once" it just a symptom of a problem not a valid solution, especially if the implementation is non-trivial. Just fix the original issue at that point.