[immich 3.0.2] How to delete unnecessary transcoded videos

[vsa-d]

Hello,
since I'm now using the real-time transcoding feature in immich 3.0.2, I changed the transcoding policy to “Do not transcode videos.” After that, I ran the “Transcode All Videos” task again. As expected, the task completed in a few minutes, but the folder containing the transcoded videos is still just as full as before.

This is the official procedure described in the immich documentation.

Has anyone tried this with the helper-script version of immich?

du -h --max-depth 1 /opt/immich/upload/encoded-video/ | sort -h -r
16G /opt/immich/upload/encoded-video/
13G /opt/immich/upload/encoded-video/bcbf6d93-7a09-4348-a3b3-0049deeaa87f
2.9G /opt/immich/upload/encoded-video/646f08b2-7406-471d-b598-6d91ab7d4654
49M /opt/immich/upload/encoded-video/35f00090-b18a-4ce0-8de4-5f7055849041
2.4M /opt/immich/upload/encoded-video/1a197a10-0cee-4803-8d26-39ddb3ed3e72

root@immich-server:~# ls -la /opt/immich/upload/ total 24
drwxr-xr-x 6 immich immich 4096 Aug 9 2025 .
drwxr-xr-x 10 immich immich 4096 Jul 12 21:07 ..
lrwxrwxrwx 1 immich immich 19 Aug 9 2025 backups -> /mnt/immich_backups
drwxr-xr-x 6 immich immich 4096 Jun 9 21:49 encoded-video
drwx------ 2 immich immich 4096 Aug 9 2025 library
drwx------ 3 immich immich 4096 Oct 18 2025 profile
drwxr-xr-x 6 immich immich 4096 Jun 9 21:23 thumbs
lrwxrwxrwx 1 immich immich 18 Aug 9 2025 upload -> /mnt/immich_upload

[vhsdream]

So if you run the 'transcode all videos' task, wouldn't that be the reason that the encoded video folder has transcoded videos in it?

From my understanding of real-time transcoding, is that when it's enabled, the videos are transcoded on the fly. The existing encoded videos wouldn't be touched, so I guess you are supposed to delete them yourself. But I don't use the feature myself, so if others have a different understanding of how it works, please contribute.

[vhsdream]

Hey @vsa-d can you link to the official documentation about realtime transcoding? I can't seem to find it and I want to check some things.

[vsa-d]

Hi,
It should be possible at least what the Immich-creators write in the FAQ in section „ How can I delete transcoded videos without deleting the original?“

https://docs.immich.app/FAQ

About on-the-fly transcoding- this was in the release notes of Immich 3.0.

https://github.com/immich-app/immich/releases

At section 3.0.0. under „HLS and Real-Time Video transcoding (preview)“

[vhsdream]

Thanks. Hmm well I wouldn't do what I suggested just yet (manually deleting the encoded videos), because I suspect there are also DB operations that occur when a job like the one you described is run which is supposed to delete the files. If you delete them manually, the DB won't know they are supposed to be gone and won't point you towards the originals.

Please enable debug or verbose logging in the Admin Logging settings, then tail either web.log, ml.log (or both) in /var/log/immich, then try running the refresh encoded videos option on one of the videos, making sure the transcode policy is set to not transcode. We'll need to see what the logs say when you do that.

[vhsdream]

I just did a test on one of mine, and it seems to have successfully deleted the transcoded file.

Before:

root@immich:/opt/immich/upload/encoded-video/f3fc48cd-bdde-4b88-xxxx-xxxxxxxxxxxx/57/10# ls -lh
total 1.5M
-rw------- 1 immich immich 1.5M Jul 13 14:28 57105cbd-9080-44af-865d-bfc5697b4e0c.mp4

After:

root@immich:/opt/immich/upload/encoded-video# ls -lh f3fc48cd-bdde-4b88-xxxx-xxxxxxxxxxxx/57/10/
total 0

[vsa-d]

...interesting! My log file (verbose) looks 1000x like this:
[Nest] 180057 - 07/13/2026, 10:19:27 PM VERBOSE [Microservices:MediaService] Asset bbc07766-5f4a-47a1-b4d4-2dae916d2a9f does not require transcoding based on current policy, skipping
[Nest] 180057 - 07/13/2026, 10:19:27 PM VERBOSE [Microservices:MediaService] Asset 50f86136-61a6-4f45-9dc9-3d5493a16dd6 does not require transcoding based on current policy, skipping
[Nest] 180090 - 07/13/2026, 10:19:27 PM DEBUG [Api:LoggingInterceptor~tilfv9yg] GET /api/queues 200 11.74ms 109.250.26.149

Nothing is beeing deleted.... :-/ Hmm.

[vhsdream]

Might be an upstream bug, but also maybe doublecheck your policy settings. Have you tried running the job with the experimental 'realtime transcode' unchecked? Maybe you need to leave it unchecked, then run the job with 'don't transcode any videos'.

[vsa-d]

Thanks for testing. I checked everything, but it did not work.
Intersting: I set the poicy setting to encode, did wait 10-15 min, so I had new encoded videos. Then I set it back to "do not encode" and started the job with "all". The new encoded videos are getting deleted:
[Nest] 385 - 07/14/2026, 4:11:09 PM DEBUG [Api:LoggingInterceptor~ell62d1n] GET /api/queues 200 69.60ms 109.250.xxx.xxx
[Nest] 385 - 07/14/2026, 4:11:12 PM DEBUG [Api:LoggingInterceptor~12x761ar] GET /api/queues 200 12.87ms 109.250.xxx.xxx
[Nest] 203 - 07/14/2026, 4:11:13 PM LOG [Microservices:MediaService] Transcoded video exists for asset 5343e635-ca0f-4808-a1e9-d62830f5f2d8, but is no longer required. Deleting...

The older files are still not getting deleted:
Nest] 385 - 07/14/2026, 4:14:53 PM DEBUG [Api:LoggingInterceptor~nqyl18uk] GET /api/queues 200 10.11ms 109.250.xxx.xxx
[Nest] 203 - 07/14/2026, 4:14:56 PM VERBOSE [Microservices:MediaService] Asset 9d6151bb-78bb-4f89-bab9-77feb423f6a7 does not require transcoding based on current policy, skipping

I use only external libraries. So it could be either an old problem (I started with immich 1.3.x or so) or a bug in immich....

[vsa-d]

Follow-up: found the root cause for my case (encoded-video not shrinking), I took some help with claude.

For anyone hitting the same issue as described above (transcode policy set to "Don't transcode any videos", running the "Transcode Videos" job with "All", but encoded-video staying huge) — here's what I found after digging into the DB on my instance (Immich 3.0.2, native install via Proxmox community-scripts helper script).

Setup: External libraries only, no uploaded originals. Transcode policy: "transcode": "disabled".

Diagnosis steps:

1. Checked how many files actually still exist vs. how many are referenced in the DB:

SELECT type, count(*) FROM asset_file GROUP BY type;

→ encoded_video: 1041 rows in DB, 1047 files on disk. So it's not orphaned files — the DB genuinely still thinks these 1041 encoded videos are needed.

2. Checked the createdAt timestamp of these rows:

SELECT "createdAt", count(*) FROM asset_file WHERE type = 'encoded_video' GROUP BY "createdAt" ORDER BY count(*) DESC LIMIT 5;

→ All 1041 rows share the exact same timestamp down to the microsecond (2026-03-20 17:30:56.316501+01). That date lines up with a past major version upgrade on my instance, not with any individual transcode job run.

Conclusion: These aren't rows created by the normal per-asset transcode workflow — they look like they were bulk-inserted by a database migration at some point (likely when the encodedVideoPath column on asset was migrated into the new asset_file table with type = 'encoded_video'). Freshly transcoded videos (created individually, one job at a time) do get correctly deleted by the "Transcode Videos" job when the policy no longer requires them — I confirmed this by manually setting the policy to "encode", letting a few videos get transcoded, then setting it back to "disabled" and running the job: those specific videos were deleted correctly with the log line Transcoded video exists for asset X, but is no longer required. Deleting.... But the ~1,041 legacy rows from the migration never hit that code path — they only produce Asset X does not require transcoding based on current policy, skipping, without ever checking/deleting the existing file.

Workaround (used on my own instance, worked cleanly):

-- confirm policy is really "disabled" first
SELECT value FROM system_metadata WHERE key = 'system-config';

-- back up your DB before doing this!
DELETE FROM asset_file WHERE type = 'encoded_video';

...then manually delete the corresponding files under .../encoded-video/, restart the immich services. This freed ~16GB on my instance and playback is unaffected (real-time/on-the-fly transcoding handles playback since the policy is "disabled" anyway).