A media library let the upload form tell the server what kind of file it had received and what aspect ratio it should display. That worked until the form's claim and the bytes on disk disagreed. The useful test was a PNG image deliberately given an .mp4 filename.
Three answers to one question
The server measured the saved file rather than accepting the form fields. For the disguised sample it recorded the kind as image and the aspect ratio as 4:3. It kept the extension as mp4, because that was still the name the file arrived with. None of those three fields had to lie to make the others look consistent.
At first I expected the viewer itself to be broken by the old classifications. Reading its rendering path showed otherwise: it chose the media element from the measured MIME type. The wrong kind mostly surfaced as a wrong label. Repairing the label was still worthwhile, but knowing which layer was wrong kept the fix in proportion to the problem.
Repairing the existing library
The backfill checked 174 stored assets and changed 168 classifications. It preserved three special role labels, since “storyboard sheet” and “derivative” describe what an asset is for, rather than what its bytes are. A second run made no further changes.
The aspect ratio field had a similar trap. Reducing measured dimensions to a fraction produced labels such as 1883:1324, exact but unhelpful in a filter menu. I kept the measured width and height, then chose the closest of seven standard display ratios for the label. Exact measurements and useful categories can coexist when they are stored as different facts.