Transcoding difficulties
It seems that ffprobe is having difficulty so end result is no transcoded video. 🤔
32 Replies
Have you pulled the file and checked if it plays OK etc?
Huh, it seems to be corrupt.
Even exiftool says file format error.
Might be tricky, but any chance you can find a version of the file from before it went into immich?
Off your phone or such
What's the DB query to figure out the original file name from assetid?
Good q, sec
It would be useful to have list of the main DB queries that one might need to figure out things like these somewhere documented.
select "imageName" from exif where "assetId"='3852f850-38ad-4f20-898a-87ce392323cc';Well, that show's nothing. :D
There is nothing in exif table about it.
Oh, right should use proper id. :D
:')
Hmm, used
ad2d646a-1b58-48dd-a6f2-81effb02bd67 and still nothing.
Other ideas? :D @bo0tzzHmmm
Is there a
Error in video metadata extraction log for that same asset?
Cause if that job fails, it doesn't save the original name to the database
And it likely would fail on a corrupt file as it does ffprobeThere is thumbnail errors, and the video conversion but no metadata.
Can you run "extract missing metadata" and see what it does?
Well,
Cannot know which asset it's talking about.
Ooh fun
That's the exif extract, not video metadata, so that's a different asset
Both of those metdata jobs need better error handling. They're both wrapped in a huge try/catch that just gives up if anything goes wrong. They do still have some data that could be saved anyways (such as the original filename from upload).
Also the input should be sanitized/validated before trying to push to the db. ;)
Yup
Let's see what happens:
I originally only did "missing", so let's test all.
Well, it doesn't log it properly so that's why I couldn't grep via assetid...
@bo0tzz That definitely needs better error handling.
GitHub
Metadata extraction jobs need better error handling · Issue #2229 ·...
Both the image exif and video metadata jobs need better error handling. Currently, both are wrapped in one big try/catch that just gives up on any errors. Meanwhile, any bad data that doesn't c...
I can't think of a way to find the original filename in this case atm
Maybe originalPath in the assets table?
You could take the path from the error -> where originalPath='' -> assetId, but it errored before the original filename was saved to the db, so that's just not in there
But it is
select * from assets where "id"='ad2d646a-1b58-48dd-a6f2-81effb02bd67'; does return things.But it wouldn't return the filename as it was on your phone
Because that's saved to the
exif table by the job with bad error handlingWell, it kinda does.
deviceAssetID has it as part of it
(Uploaded from web)
Oh, interesting, I didn't know it does that
I thought that was always uuid
So then you can locate the untouched pre-upload file, right? Is that also corrupted?
That would be correct.
So immich didn't kill it then
Phew 😅
But still that's... an interesting error case.
Next question is how do I yeet the assets that don't have thumbs and/or exif?
Yeah, idk if we can really do anything with files that are that broken. Maybe just shift it into a separate folder, log a big fat error, and forget about it?
There's no easy way I think. Find them in the DB, manually clean them from assets table (and any relations, though on broken files those shouldn't've been created yet atm), and manually clean them off disk.