Regenerating thumbnails doesn't relink all of them inside the database

[NyaomiDEV]

The bug

After migrating to WebP from Jpeg I noticed that all of the Jpeg files were left over inside the thumbnails folder, so I just... find . -type f -name "*.jpeg" -delete'd them, thinking I'd be fine. To be honest, I am still fine, they are previews and my actual library resides somewhere else, however I found a bug.

The bug is, I think Live Previews do have a thumbnail of their own which means extra storage used. Why is that? Probably it's there by design - but anyway... the ACTUAL bug is, sure the job regenerated their thumbnails into WebP format, but it forgot to update the database, it seems, because in my Offline Paths section now I have 1048 missing assets and faces and from taking a look to some of them manually:

• they've all been reconverted to WebP
• of course I removed their Jpeg counterpart

Also, the thumbnails job doesn't seem to regenerate any of the people's faces previews, so they're now all missing from my library.

The OS that Immich Server is running on

Arch

Version of Immich Server

v1.102.3

Version of Immich Mobile App

Not applicable

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

version: "3.8"
services:
  immich_server:
    image: ghcr.io/immich-app/immich-server:release
    command:
      - start.sh
      - immich
    volumes:
      - /data/immich/photos:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    environment:
      DB_HOSTNAME: postgres
      DB_USERNAME: postgres
      DB_PASSWORD: postgres
      DB_DATABASE_NAME: immich
      REDIS_HOSTNAME: redis
    depends_on:
      - redis
      - postgres
    networks:
      - default
      - nginx_default
    restart: always
  immich_microservices:
    image: ghcr.io/immich-app/immich-server:release
    command:
      - start.sh
      - microservices
    volumes:
      - /data/immich/photos:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    environment:
      DB_HOSTNAME: postgres
      DB_USERNAME: postgres
      DB_PASSWORD: postgres
      DB_DATABASE_NAME: immich
      REDIS_HOSTNAME: redis
    depends_on:
      - redis
      - postgres
    networks:
      - default
    restart: always
  immich_machine_learning:
    image: ghcr.io/immich-app/immich-machine-learning:release
    volumes:
      - model-cache:/cache
    environment:
      DB_HOSTNAME: postgres
      DB_USERNAME: postgres
      DB_PASSWORD: postgres
      DB_DATABASE_NAME: immich
      REDIS_HOSTNAME: redis
    networks:
      - default
    restart: always
  redis:
    image: registry.hub.docker.com/library/redis:6.2-alpine@sha256:51d6c56749a4243096327e3fb964a48ed92254357108449cb6e23999c37773c5
    networks:
      - default
    restart: always
  postgres:
    image: registry.hub.docker.com/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: immich
    volumes:
      - /data/immich/db:/var/lib/postgresql/data
    networks:
      - default
    restart: always
volumes:
  model-cache: null
networks:
  default: null
  nginx_default:
    external: true

Your .env content

nothing here

Reproduction steps

1. Have some photos with live previews
2. Migrate previews to WebP and run the thumbnail job for all assets
3. Delete all the Jpegs from the thumbnail cache
4. Observe issue

Relevant log output

No response

Additional information

Probably I was stupid to use that option when it first dropped.

[mertalev]

Thanks for the detailed issue!

After migrating from WebP to Jpeg I noticed that all of the Jpeg files were left over inside the thumbnails folder

This is an oversight. It used to be that there was only one possible path, so re-running thumbnail generation could only overwrite the existing thumbnail. But now we need to clean up more explicitly to avoid having leftover images.

I think Live Previews do have a thumbnail of their own which means extra storage used. Why is that?

This was a bug that was recently fixed in #8891. It’s because we mostly treat the motion part as a regular video in jobs.

the ACTUAL bug is, sure the job regenerated their thumbnails into WebP format, but it forgot to update the database, it seems, because in my Offline Paths section now I have 1048 missing assets and faces

I think it’s the opposite. They show up as untracked because the paths in the DB were updated, so there’s no longer any reference to them. We should change the job to clean up the old thumbnail.

[NyaomiDEV]

I think it’s the opposite. They show up as untracked because the paths in the DB were updated, so there’s no longer any reference to them. We should change the job to clean up the old thumbnail.

At first there were untracked paths (a ton of Jpeg thumbnails indeed), however after my brutal attempt at cleanup I have offline paths!

Again, if I take a look at the actual paths, the offline path ends in .jpeg, but there is a .webp counterpart available.

[NyaomiDEV]

What I think happened is that the job runs for all thumbnails including live previews, but since the live previews are "invisible" the thumbnail reference doesn't get updated in the database (it's supposed to not even exist by now). Since I have an Immich instance that existed before that MR you pointed me at, probably it's an issue for upgraded instances only, as they still have live previews with a generated thumbnail and a reference to that.

However this should mean that, in new instances, there'd be a lot of untracked files in the case someone also stores live previews. I think that may also happen if a live preview video is uploaded before the image counterpart and the two are still not linked (on a fast server perhaps?) but that's only speculation.

[mertalev]

I think that may also happen if a live preview video is uploaded before the image counterpart and the two are still not linked (on a fast server perhaps?) but that's only speculation.

Oh, you're right: the motion part can still end up going through the full pipeline before it's linked. I'm not sure how often this would happen, but it's a bit unfortunate that it can. I guess the best we could do there is to clean it up during linking after it wastes time processing them.