Host CPU is an old Xeon E5530 (2010-era, no hardware encode available at all)
already fairly loaded, so raw compute is the real bottleneck. Two changes:
- Cap ABR renditions to the 2 highest applicable instead of up to 4 — roughly
halves total encode work per job while still giving a real high/low
adaptive-bitrate pair.
- veryfast -> superfast x264 preset, a meaningful further speed win at the
cost of somewhat larger files and slightly softer quality per bitrate.
Combined, remaining variants also get more threads each since fewer variants
now share the same TRANSCODE_THREADS budget.
-progress pipe:1 -nostats belong to ffmpeg, not nice — they were landing right
after cmd[0] (nice) instead of after the ffmpeg token, which made nice choke
on an unrecognized option and fail before ffmpeg ever started.
- 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