[Bug] Paid-content 10% video previews unplayable (truncated MP4) #35
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
content.preview-peer returns base64 of the first ~10% of the file; for non-faststart MP4 the moov atom is at the end, so a 10% prefix will not play. Free content streams fine via /api/peer-content (Range). Fix needs backend: generate proper preview clips (ffmpeg faststart / first-N-seconds) or serve previews moov-first. Frontend now shows a clear error overlay (commit
c481afc7). (Found 2026-06-16)Deferred: needs the serving node to generate a real preview clip (ffmpeg faststart / first-N-seconds). Frontend now shows a clean error overlay instead of a black box.
STATUS: pure-Rust MP4 fix approach approved earlier but not yet implemented this session (focus was on the live fleet bugs + the DHT merge). Still open; next when prioritised.
Fixed: the preview path no longer streams an unplayable byte-prefix for non-faststart MP4s.
content_server.rsnow scans the MP4 top-level boxes and only serves a truncated preview when the file is faststart (moovbeforemdat, i.e. a prefix is playable); non-faststart media returns a newPreviewUnavailable(HTTP 415 +X-Content-Preview: unavailable) so the UI shows its 'preview unavailable' overlay (shippedc481afc7) instead of a stuck player. Unit testsdetects_faststart_*pass. NOTE: full preview-clip generation (re-encode/first-N-seconds) is a separate enhancement — it needs ffmpeg, which isn't on the node host (would run via the IndeeHub ffmpeg container).