Human-126094

🚀 v2.42.0 - Clear NVENC "API too new" diagnosis ghcr.io/masterjb/x265-butler:2.42.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler This is a small diagnostics release. When NVENC refuses a card with "Required: X.Y Found: A.B", the app now tells you what it actually means, the GPU's NVENC API is older than the encoder was built for (a hardware-generation limit on Pascal/Maxwell, not a driver you can update), instead of the old misleading "update your driver" hint. v2.41.0 already fixed the normal path (NVENC routes to the bundled jellyfin-ffmpeg), so you'll only see this via the FFMPEG_NVENC_PATH=ffmpeg revert lever or a card older than jellyfin's floor. No encode behaviour changed - QSV / VAAPI / libx265 / NVENC / bench / VMAF are all byte-for-byte identical. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.42.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.41.0 Keep the reports coming, the cryptic-error cleanups like this one come straight from them.

🚀 v2.41.0 - Pascal/Maxwell NVENC support is live ghcr.io/masterjb/x265-butler:2.41.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler If you have an older NVIDIA card, Pascal (Tesla P4, GTX 10-series) or Maxwell (GTX 9-series), NVENC now works. Before this release those cards were refused with "Required: 13.1 Found: 13.0" and silently fell back to CPU encoding, because our ffmpeg build (BtbN) has an NVENC API floor of 13.1 compiled in and those cards top out at 13.0. The fix ships a SECOND ffmpeg - jellyfin-ffmpeg - used only for NVENC. It has an older NVENC floor so Pascal/Maxwell cards encode, and modern RTX cards keep working too (the floor is backward-compatible). Everything else is unchanged: the primary BtbN ffmpeg still handles QSV, VAAPI, libx265, cropdetect, ffprobe and the VMAF quality bench. An encode routes to the jellyfin binary only when the encoder is NVENC. Your existing settings carry over untouched. (Trade-off: the image grew ~100 MB for the second binary.) Escape hatch: if you want NVENC back on the old binary, set container env FFMPEG_NVENC_PATH=ffmpeg (this re-triggers the Pascal refusal - it is a revert lever, not a fix). 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.41.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.40.0 🔭 COMING NEXT • A clearer diagnostic message for the NVENC API-floor case (instead of the cryptic "Required: 13.1 Found: 13.0") Plans can shift, but that's the current direction. More of the same rolling bug-stabilisation from your reports, keep them coming in this thread

@obideuce the Pascal NVENC fix is ready for you to test on a dev build 🎉 Quick recap of what changed: instead of swapping our ffmpeg (which would have broken the VMAF quality bench, since the Pascal-capable build ships no libvmaf), the image now carries TWO ffmpeg binaries. The normal BtbN one stays for QSV/VAAPI/x265/bench, and a second jellyfin-ffmpeg binary (older NVENC floor) handles NVENC only. So your Tesla P4 should finally encode instead of falling back to CPU. It's on the dev image, not a release tag yet, I need your P4 to confirm before I ship it. STEP 1 pull the dev image: docker pull ghcr.io/masterjb/x265-butler:dev Confirm you actually got a fresh image (the id should change from before): docker inspect --format '{{.Id}}' ghcr.io/masterjb/x265-butler:dev STEP 2 run the NVENC probe against the NEW binary (note: ffmpeg-nvenc, not ffmpeg). Assumes your container is named x265-butler and is running with --runtime=nvidia + NVIDIA_DRIVER_CAPABILITIES=compute,video,utility: docker exec x265-butler ffmpeg-nvenc -hide_banner -f lavfi -i testsrc=size=320x240:rate=30 -frames:v 30 -c:v hevc_nvenc -f null - 2>&1 | tail -20 WHAT I'M HOPING TO SEE: a "frame= 30" line and exit 0, NOT the old "Required: 13.1 Found: 13.0" refusal. That's the GO signal. STEP 3 sanity check in the Butler UI: • Encoder detection now lists NVENC as working (not a silent libx265 fallback) • The "Test encode" button on the Diagnostics page succeeds for NVENC • A real encode with the encoder set to NVENC completes STEP 4 (optional, nice-to-have) 10-bit HEVC on the P4: docker exec x265-butler ffmpeg-nvenc -hide_banner -f lavfi -i testsrc=size=320x240:rate=30 -frames:v 30 -pix_fmt p010le -c:v hevc_nvenc -f null - 2>&1 | tail -20 Same "frame= 30" + exit 0 = 10-bit works too. If this one fails but Step 2 passed, no problem — 8-bit is the fix, 10-bit would just be a known gap. Paste back the tail output from Step 2 (and Step 4 if you try it). If it's "frame= 30" I'll tag the release; if it's another "Required: … Found: …" line on the fresh dev image, that tells me the floor is still too high and I re-scope. Thanks for being the P4 test bench, no way to validate this without your hardware 🙏

Thanks for the report, the Required: 13.1 Found: 13.0 line pins it exactly. Your Tesla P4 is Pascal, and the bundled FFmpeg is compiled against NVENC headers that demand a driver newer than any Pascal driver branch (580) can provide. The NVENC minimum is baked into the binary at compile time, so there's no setting to flip, it needs a different FFmpeg build. I have a candidate fix (swap the bundled FFmpeg for a build with an older NVENC floor that still runs on modern cards too). Before I rebuild, could you run these 4 commands on your unRAID host and paste the output? Command C is the important one, it proves the fix works on your actual P4 before I ship anything. A — your exact GPU + driver: nvidia-smi --query-gpu=name,driver_version,compute_cap --format=csv B — reproduce the failure with Butler's current FFmpeg (replace x265-butler if your container name differs): docker exec x265-butler ffmpeg -hide_banner -f lavfi -i testsrc=size=320x240:rate=30 -frames:v 30 -c:v hevc_nvenc -f null - 2>&1 | tail -20 (expected: the Required: 13.1 Found: 13.0 error) C — proof-of-fix: same NVENC test, but with the candidate FFmpeg build, on your P4: docker run --rm --runtime=nvidia --gpus all -e NVIDIA_DRIVER_CAPABILITIES=all --entrypoint /usr/lib/jellyfin-ffmpeg/ffmpeg jellyfin/jellyfin:latest -hide_banner -f lavfi -i testsrc=size=320x240:rate=30 -frames:v 30 -c:v hevc_nvenc -f null - 2>&1 | tail -20 (if this ends with frame= 30 and no error → the fix will work for you. If it shows another Required: … Found: … line → it won't, and I'll need a different approach.) D — encoder parity check on the candidate build: docker run --rm --entrypoint /usr/lib/jellyfin-ffmpeg/ffmpeg jellyfin/jellyfin:latest -hide_banner -encoders 2>/dev/null | grep -Ei 'nvenc|qsv|vaapi|libx265' And 3 quick questions so I scope it right: 1. Besides the Tesla P4, do you run any other older NVIDIA cards (Maxwell GTX 9xx, other Pascal) you'd want supported? 2. On the P4 you only need HEVC encoding, correct? (Pascal can't do AV1 encode either way.) 3. Once I have a fix, can you pull a :dev image and re-run command B (now expecting success) on the real P4 before I tag the release?

🚀 v2.40.0 - Encoding Profile card is live ghcr.io/masterjb/x265-butler:2.40.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler This one is pure UI tidy-up: the three per-encode video toggles - Auto-Crop, Force 10-bit, and Colour/HDR10 passthrough - now sit together under one "Encoding Profile" card in the Encoder settings tab instead of being scattered across separate cards. That delivers the "gather the per-encode toggles into one place" note from the last release. No encoder code changed - your encodes come out byte-for-byte identical to v2.39.0, and your existing toggle states carry over untouched. Nothing to re-configure after the upgrade. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.40.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.39.0

🚀 v2.39.0 - 10-bit toggle, per-encode ETA, and "same as source" colour + HDR10 ghcr.io/masterjb/x265-butler:2.39.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler This one is the HandBrake-style "near-passthrough" bundle a few of you asked for: keep the source bit-depth and colour, and show how long an encode has left. Three opt-in features, all default-OFF, so nothing changes on your existing setup until you flip a switch. 🔟 FORCE 10-BIT OUTPUT (new Setting, default OFF) Encodes every output as 10-bit HEVC (Main10) regardless of source depth, good for banding-prone gradients and a uniform archive depth. Works on all four encoders (libx265 / NVENC / QSV / VAAPI). OFF = output byte-identical to before. ⏱️ PER-ENCODE ETA IN THE QUEUE Each running encode now shows a live ETA next to its progress, derived from ffmpeg's own reported speed (no extra flag, no overhead). Refreshes on the existing ~30s progress cadence and reflects the real speed at your chosen preset. 🎨 PRESERVE SOURCE COLOUR + HDR10 (new Setting, default OFF) Carries the source colour signalling onto the re-encode instead of letting it default, the fix for washed-out colour / HDR after re-encode. One toggle covers both: • Colour VUI tags - colour space, primaries, transfer (e.g. BT.2020 / PQ), range. • HDR10 static metadata - mastering-display colour volume + MaxCLL/MaxFALL, so HDR displays tone-map correctly. OFF = output bytes unchanged. HARDWARE-ENCODER NOTE (NVENC / QSV / VAAPI): for the hardware encoders, 10-bit and HDR10 preservation ride ffmpeg's automatic side-data passthrough rather than an explicit per-encoder flag. Validated directly on libx265; on hardware it is best-effort and operator-validated. After a hardware encode of an HDR10 source with "Preserve source colour" ON, confirm it survived: ffprobe -hide_banner -show_streams <output> | grep -iE "mastering|content light" Expect a "Mastering display metadata" line and a "Content light level metadata" line. If you run a hardware encoder, a quick report either way is very welcome. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.39.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.38.2 🔭 COMING NEXT Rough outlook (plans can shift): • A general encoding-options UI: gather the per-encode toggles (10-bit, preserve-colour/HDR10, auto-crop, output mode...) into one place instead of scattered individual Settings, so you can dial in a profile without hunting. This release's three toggles are the first batch that UI will surface.

Thanks for the kind words and the detailed write up. Really helpful to know your exact workflow. 😊 Good news: most of what you describe is already how the encoder works today. It copies audio, subtitles, metadata and attachments untouched, applies no filters, doesn't touch framerate, and keeps the source bit depth (8 bit source stays 8 bit, 10 bit stays 10 bit, exact necessary already ships too (auto crop). So your "almost passthrough" case really only needs two small additions, both now planned: 1. Force x265 10 bit. An opt in toggle to encode even an 8 bit source as 10 bit bit" option, less banding and often better compression). 2. ETA per encode. Bringing the estimated time remaining back onto the running job view. Plus a small hardening so color range and primaries are explicitly carried through as "same as source". The broader "expose all encoding options" idea (deinterlace, denoise, tune, profile dropdowns) is a bigger change and, as you said, not everyone needs it. So I split that into a separate later step rather than holding up the part you actually need. Targeting these for an upcoming release. Will report back here when there's a build to test. Thanks again!

🚀 v2.38.2 - Poll-rate diagnostics now measured, not estimated ghcr.io/masterjb/x265-butler:2.38.2 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler v2.38.1 killed the watcher stat-storm on FUSE/shfs shares (confirmed on real hardware: ~59,000 → ~1,000 statx/sec). But the poll-rate number on the Diagnostics page still under-reported the real rate by about 3x - it printed an ESTIMATE from a fixed "10 paths per watched file" guess that doesn't fit every library shape. v2.38.2 makes that number real: each forced-polling share now reports the chokidar-MEASURED watched-path count (actualWatchedPaths / actualStatsPerSec / actualPathMultiplier) right next to the old estimate, so you can audit the stat-rate straight from /api/diagnostics without an strace. Diagnostics-only: the actual poll cadence and stat-rate on your host do NOT change vs v2.38.1 only the number the page prints for it becomes correct. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.38.2 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.38.1

Thanks, that strace is exactly the smoking gun, and your read is spot on. You nailed it: there WAS a second stat path not represented by pollingShares. It wasn't a separate scanner, it was chokidar's second poll knob. Chokidar's forced-polling mode has two intervals: "interval" for ordinary files, and "binaryInterval" for binary-extension files (.mkv/.mp4/.jpg/.png), which defaults to 300 ms. v2.38.0 only scaled "interval". Since your library is basically all binary extensions (video plus .jpg/.png artwork), every one of those paths kept polling at the 300 ms default. So WATCH_POLL_INTERVAL_MS=60000 was genuinely active (your diagnostics were honest), it just didn't govern the binary knob. That's the 169x gap between the ~350/s estimate and the ~59k/s you measured. This is fixed in v2.38.1 (just shipped): both poll knobs are now pinned to the same resolved interval, so the value you set governs the whole tree, artwork and video included. Please pull and restart: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler Then re-run the same 10s strace with WATCH_POLL_INTERVAL_MS=60000 still set. The ~591k/10s down toward the diagnostics computedStatsPerSec order (a few hundredper second, not tens of thousands). Would really appreciate a fresh strace sample after the upgrade to confirm it on your hardware. Your captures have been exactly what was needed to pin this down.

🚀 v2.38.1 - Watcher poll-storm hotfix is live ghcr.io/masterjb/x265-butler:2.38.1 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler Hotfix on v2.38.0: the file-watcher poll fix only governed one of chokidar's two poll knobs, so on a media library (mostly .mkv/.mp4/.jpg/.png) the binary-file poll kept running at 300 ms and the stat-storm survived even with WATCH_POLL_INTERVAL_MS set. v2.38.1 pins both knobs together, so the interval you set now flattens the whole tree. No config change needed - existing installs benefit automatically. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.38.1 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.38.0

🚀 v2.38.0 - Watcher poll-pool stat-storm fix is live ghcr.io/masterjb/x265-butler:2.38.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler If your library lives on a user-share (FUSE/shfs) and the web UI got sluggish while encodes ran - pages crawling, sometimes never loading, this is the fix. The file-watcher's polling mode was hammering the filesystem with a stat-storm (~62.000 stat calls/s on an 11.685-file share, strace-confirmed) that saturated Node's I/O thread pool, so every page-load queued behind it. v2.38.0 scales the poll interval with library size to cut that stat-rate by 10x or more. inotify shares (ext4/xfs) are unchanged; encodes were never affected. New WATCH_POLL_INTERVAL_MS env knob lets you pin it manually, and /api/diagnostics now shows the per-share polling state so the storm is visible without a shell. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.38.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.37.0

Thanks for the detailed test, that's exactly the data I needed, and your read was on the right track. I shipped v2.37.0 which fixes precisely this. Two things were going on: 1. The 4K "stdout exceeded cap" kill. It wasn't the resolution or the log size, it was duration. ffmpeg's machine-readable progress stream (not the x265 console output) emits ~2 lines/sec, so a ~5.5h 4K encode piled up ~40,000 progress blocks (~8.4 MB) and tripped an 8 MB stdout guard, which killed the job near the end. 1080p/720p finished faster, stayed under the cap, so they succeeded. That's why both 4K logs froze around ~13 MB while the 1080p one reached 24 MB, the 4K jobs were killed mid-stream, the 1080p one ran to completion. 2. The truncated job log. Same root cause, the progress stream was flooding the log, so "copy report" was 99% progress spam. v2.37.0 throttles progress to one update every 30s (the same 5.5h encode now produces ~660 blocks, ~140 KB, nowhere near the cap), and it no longer dumps the progress stream into the job log, so "copy report" now shows the real ffmpeg/x265 output. To update: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler Could you re-run the two 4K files once you're on 2.37.0? They should now run to completion, and the copied job log should be readable. Thanks again for the logs!

🚀 v2.37.0 - Output Stream-Mapping Hardening is live ghcr.io/masterjb/x265-butler:2.37.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler Two encode-output fixes from real footage: iPhone .MOV clips that refused to encode, and long 4K encodes that self-killed hours in. 🎬 IPHONE .MOV NOW ENCODES Every iPhone .MOV failed instantly, exit 234, 0 frames, "Only audio, video, and subtitles are supported for Matroska". It looked like it failed near the end, but the mux header was actually refused before the first frame. Cause: the iPhone attaches Apple timed-metadata (mebx) data streams that Matroska rejects, and we were copying every stream into the MKV. Now the MKV path maps only video/audio/subtitle and attachment streams (your anime ASS fonts are kept) and drops the incompatible ones. MP4 output is unchanged. 🐢 4K ENCODES NO LONGER SELF-KILL If you saw a 4K encode run for hours and then die with "encode:stdout exceeded cap" (cause in the job transition log) while 1080p/720p finished fine, this release fixes exactly that. It was duration-bound, not resolution- or log-size-bound: ffmpeg's progress stream emitted ~2 blocks/sec, so a ~5.5h 4K encode piled up ~40k blocks (~8.4 MiB) and tripped an 8 MiB stdout guard, killing the job near the end. (Your hunch that 4K "generates too much log and saturates stdout" was on the right track, it's the machine-readable progress stream specifically, not the x265 console output.) Progress is now throttled to one update every 30s, so the same encode produces ~660 blocks (~140 KiB) and never gets near the cap. Bonus: the job log "copy report" no longer fills up with progress spam, it now shows the real ffmpeg/x265 output, so the truncated-log problem is gone too. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.37.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.36.1 🔭 COMING NEXT Plans can change, but on the bench right now: • Sharper diagnosis of UI sluggishness during heavy encodes (CPU attribution sampler, waiting on a QSV capture from an affected host) • More robust hardware-encoder detection on multi-GPU / mixed Intel+AMD boxes As always - if something breaks on your hardware, drop the diagnostics copy-report here and I'll dig in.

Thanks a lot for the very detailed captures, the thread samples, the UI-closed test and the diagnostics report together make the picture clear, so I want to confirm the exact cause before changing anything. Your data points strongly at libuv thread-pool saturation from background filesystem work (not JS, not the database). To nail it down, please run this while the problem is happening, i.e. with your 2 QSV encodes running and the web UI feeling sluggish (not on an idle system, otherwise we miss the exact state we're measuring): docker exec x265-butler sh -c 'timeout 10 strace -f -c -p 1 2>&1 | head -30' What it does: attaches to the x265-butler Node process for 10 seconds and prints a summary of which Linux system calls it made and how often. If the top is dominated by newfstatat/statx (file-stat calls), that confirms the file-watcher is the cause; if it's read/pread64, it's a different path. Either way it tells us exactly where to fix it. The command only observes, it changes nothing and doesn't affect your encodes. Paste me the top lines and I'll take it from there.

🚀 v2.36.0 - AMD/VAAPI card no longer lost after a fresh-install restart ghcr.io/masterjb/x265-butler:2.36.0 and :latest are up. amd64-only image on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler If your AMD card went missing after restarting on a fresh install - encoding dropping back to CPU until you restarted again - this is the fix. At boot the app was probing for hardware AND starting the queue at the same time, so a real encode could grab the AMD card's single encode session right when the detection probe needed it. The probe failed, the card got marked "broken", and that was cached until the next restart. Detection is now single-flight: the boot probe and the queue share ONE detection run instead of two competing VAAPI probes, and the first encode only starts after detection finishes on an idle GPU. A failed detection is no longer cached either - the next try re-probes fresh. • If a card ever drops out, the "Re-detect hardware" button on the /diagnostics page re-runs detection on demand (with a before/after diff) - no restart needed. No new dependencies, no migrations, encode output byte-identical to v2.35.x. 🟢 NVIDIA NVENC - HOST SETUP RECAP (applies to all versions) If you run an NVIDIA card, NVENC needs the host driver (unRAID NVIDIA-Driver-Plugin or nvidia-container-toolkit) plus these on the container: Extra Parameters: --runtime=nvidia Variables: NVIDIA_VISIBLE_DEVICES = all NVIDIA_DRIVER_CAPABILITIES = compute,video,utility The "video" capability is the one that bites you: the runtime default is compute,utility and WITHOUT video the NVENC session fails to init even though nvidia-smi works fine. utility = the detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK If v2.36.0 misbehaves on your hardware, roll back to the previous image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.35.0 🔭 COMING NEXT • iPhone / .MOV encodes that fail right away - if an iPhone clip dies before frame 1 ("never finishes, always fails near the end"), it's the Apple timed-metadata track the file carries that the MKV container rejects. Next release teaches the encoder to drop those container-incompatible side tracks so the encode just runs. • Web UI staying snappy under load - better CPU prioritisation so the pages don't get sluggish while several encodes run at once. Plans can change, but that's what's on the bench.