You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a4973ec
Browse filesBrowse the repository at this point in the historyBrowse files
fix(files): render audio and video stored as application/octet-stream (#6341)
* fix(files): render audio and video stored as application/octet-stream
The file viewer built the blob backing <audio>/<video> from the record's stored
content type with a truthiness fallback, so a stored application/octet-stream
was passed straight through and the element could not determine the format.
Downloading the same file worked because the download path derives its content
type from the filename.
- Add resolveEffectiveMimeType, which resolves a generic stored type against the
filename, and use it for the media blob, the type column, and the type filter
(an octet-stream video was also invisible to the Audio/Video/Image filters)
- Map .webm to video/webm rather than audio/webm: a <video> element plays an
audio-only stream, an <audio> element drops the picture
- Preview .bmp, .avif and .ico, which upload accepts but the viewer sent to the
download-only path; serve them with their real content type so nosniff does
not block them. .tiff and .heic stay unsupported - no browser renders them
- Open .jsonl in the text editor, and fill the extension-to-mime gaps for
.mmd, .diff, .patch and .fish
* fix(files): settle the audio/video container ambiguity at the call site
Follow-up to the review pass on this branch.
- Revert the global .webm -> video/webm remap. EXTENSION_TO_MIME is shared with
non-viewer callers, and a .webm with an empty stored type would have started
taking the STT route's video branch (stt/route.ts:211 -> extractAudioFromVideo),
which 500s where no ffmpeg binary is on PATH. The ambiguity is now settled in
resolveMediaMimeType, which knows which element the caller is rendering
- Resolve the public share route's Content-Type from the filename via
getContentType, matching the workspace serve route, instead of echoing the
client-declared stored type into a public unauthenticated response. Add the
audio/video entries contentTypeMap was missing so a shared media file keeps a
real Content-Type (disposition is unchanged - none are inline-safe)
- Make resolveEffectiveMimeType total (string, not string | null); the null
contract only bought one label edge case and cost a ?? at every call site,
one of which was dead
- Drop .jsonl from the text-editable set. The editor loads the whole file and
only CSV has a byte cap, so a large .jsonl would trade a download-only
fallback for a crashed tab. Needs the size guard generalized first
- Trim two comments that restated their code
* fix(files): resolve dual audio/video containers to the kind the app presents
The viewer routes .webm to the video player, but the Type column and the
audio/video filters resolved it through EXTENSION_TO_MIME and read audio/webm,
so one file showed as Audio and opened in a <video>.
resolveEffectiveMimeType now consults a DUAL_CONTAINER_MIME map first. It stays
out of EXTENSION_TO_MIME because the speech-to-text and ElevenLabs routes read
that table directly, where a video/* label pushes a .webm into ffmpeg audio
extraction it does not need.
* fix(files): keep the dual-container video default out of the persisted type
resolveFileType writes user_file.content_type, and it delegated to
resolveEffectiveMimeType, so DUAL_CONTAINER_MIME could persist video/webm. The
speech-to-text route reads that back as file.type, which sends the upload into
the ffmpeg extraction path the previous commit set out to avoid.
resolveFileType now resolves through EXTENSION_TO_MIME alone; the video default
stays on the presentation path. Both share an identifiesFormat predicate.
0 commit comments