[BUG]: "Transcode missing" job won't catch videos, where only audio codec is undesired, because there are 0 Bytes transcodes from the previous version

[Hely0n]

The bug

I have some videos, where the video codec is H264 but audio codec is something random.
There was this bug, that those weren't transcoded due to some ffmpeg flags, but with the current version, it should be fixed.

It indeed is fixed somehow. When I take one of those videos and click "refresh encoded-videos", it transcodes it successfully. But I have to add, that it only played on web after I hard reloaded with clearing cache (or maybe it took some time until the backend refreshed it). On mobile, it plays normally.

Now the real problem is, that I ran "transcode missing" and it didn't catch those videos.
I found out, that it's because I tried to transcode those videos in the previous version, where it created 0 bytes videos due to the bug. Now, the job skips those videos because there "exist"

My workaround will be to just transcode all again. But maybe it would be good if the algorithm for "Transcode missing" checks if the existent videos are not empty.

The OS that Immich Server is running on

Unraid

Version of Immich Server

v1.102.0

Version of Immich Mobile App

v1.101.0 build.147 (ios)

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

not relevant

Your .env content

not relevant

Reproduction steps

1. Have a video where video codec is h.264 and audio codec something not accepted
2. Set target codec to HEVC and AAC
3. Start "transcode missing"
4. You will notice, the videos in question are still not transcoded

But because this bug is due to created files of the previous version, I don't know how to recreate the behaviour exactly (you would have to place a 0bytes transcode for a video manually)

Relevant log output

not relevant

Additional information

No response

[mertalev]

The missing button uses the database - it doesn't check the files themselves. If a video doesn't get queued, it means the asset has a non-null value for encodedVideoPath. This field gets set at the very end after transcoding is complete, meaning it only gets set if there was no error.

Since the dashboard doesn't refresh that often, it can also be that it does get queued, but is skipped based on the transcode policy.

[mertalev]

Ah, but we don't handle FFmpeg failures very well. If it ran and deleted a previously existing transcode and then threw an error, the result would be a 0 byte file that wouldn't get queued because it already had encodedVideoPath populated. Does that sound like this might be what happened?

[Hely0n]

Yes I would say, that's exactly the case