- ffmpeg progress streamed via -progress pipe:1, persisted on the job as a percent
- retry/retry-all now mark the old row as superseded instead of deleting it,
preserving the failed/cancelled audit trail
- frontend shows the running job in its own panel above the list with a live
progress bar instead of burying it as just another row
Root cause of "movies have no volume control / can't hear anything":
0 of 200 movies had finished transcoding, so every movie streamed its
raw source file — and BDRip/AVI sources very commonly carry AC3/DTS/EAC3
audio, which no browser can decode natively. Browsers respond by hiding
the volume control entirely when they can't find a playable audio track,
which is exactly the symptom reported.
New "audio" transcode quality: video is stream-copied untouched, only
the audio track is re-encoded to AAC — dramatically faster than a full
ABR pass since no video re-encoding happens. Added:
- transcode_audio_fix() in transcode.py
- "audio" as a valid quality value everywhere quick/abr were validated
- POST /transcode/queue/fix-audio-all: cancels every still-pending job
and replaces it with the fast audio fix for the same content (running
jobs are left alone), so a library-wide backlog of slow ABR jobs can
be swapped for something that actually restores sound soon
- Per-movie "Audio" button in Admin, "Fix Audio (Fast, All)" button on
the Transcode Queue page
Note: this doesn't help HEVC/x265 sources, whose video (not just audio)
isn't natively browser-playable either — those still need a full ABR
re-encode to H.264.
Setting -threads:v:i to the full TRANSCODE_THREADS on every variant let
each of the (up to 4) ABR renditions ask for the full budget independently
-- confirmed live on CT104: ffmpeg was still pulling ~7 of 8 cores despite
the "cap". Now divides the budget across however many variants are in
this job (6 threads / 4 variants = ~1-2 each), so the total stays near
the intended cap regardless of source resolution.
- nice level 19 -> 10 (was the absolute lowest CPU priority) and cap
ffmpeg to 6 threads on this 8-core host, leaving headroom for Mongo,
the *arr stack, and the API itself instead of an unbounded encode.
- Add POST /transcode/queue/retry-failed to re-queue every failed/
cancelled job at once; label the per-job Retry button with text
(was icon-only) and clarify in the page copy that failed/cancelled
jobs never delete the movie — retry just re-queues the same file.
Myron Blair