Human-126094

🚀 v2.32.0 - Auto-Crop / Black-Bar Removal is live ghcr.io/masterjb/x265-butler:2.32.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 for everyone with letterboxed or pillarboxed sources (black bars baked into the picture). x265-butler can now detect and crop those bars out during the encode - the same idea as Handbrake's "crop = auto". Cropping the dead bars saves bitrate and gives a cleaner output. ✂️ AUTO-CROP + MANUAL OVERRIDE New card under Settings -> Encoder -> Auto-Crop, with two controls: • Auto-Crop toggle - runs an ffmpeg cropdetect pass on a short sample of each source, figures out the crop, and applies it to the encode automatically. Per-file, so each title gets its own crop. • Crop override (W:H:X:Y) - a fixed geometry for when you already know the exact crop, or when auto-detect guesses wrong. A valid override wins over the toggle, so you can leave Auto-Crop off and still force one specific crop. Bad/odd values are rejected right in the form and at the API, so you get told immediately instead of a failed encode later. The first-run onboarding now mentions where to find this too. Both controls are OFF by default. If you do not touch them, the encode is byte-identical to v2.31.x - nothing changes for you. Works across libx265, NVENC, QSV and VAAPI. 🟢 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.32.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.31.0 🔭 COMING NEXT • Central-sidecar re-queue fix - if you store sidecars centrally and keep the source files, rescans can re-queue already-encoded files. A write-side fix is planned. • Per-encode progress bars - the queue progress bar can disappear, and with parallelism set to 2 or more each running encode should show its own bar. Feedback and crop results from real hardware welcome - especially QSV/VAAPI/NVENC, since I cannot test the cropped HW encode locally.

Hi @cmeyer86 thanks for the detailed report. Trash on a separate path: this is already possible. Open Settings and look for the Trash Path field. Leave it empty to keep the trash on the cache pool, or point it at an array share so the files can live there for the retention window (default 30 days). The path is fully adjustable. Queue picking up already encoded files: I could reproduce the cause and added a fix to the pipeline. It will land in one of the next releases. Progress bar: both points (the bar disappearing, and one bar per encode when parallelism is 2 or higher) are queued as well and ship in the same line of updates. Cheers

🚀 v2.31.0 - GPU Device Selection is live ghcr.io/masterjb/x265-butler:2.31.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 run more than one GPU, you can now choose which one encodes. Before this, x265-butler always used the first /dev/dri/renderD* node it found - usually the Intel iGPU - so a discrete card like an Arc A380 was never picked up and there was no way to override it. This release adds a GPU device picker. 🎛️ WHAT'S NEW • New "GPU Device" picker in Settings → Encoder, and a matching one in the first-run onboarding hardware step. • Both lists are filled from a live probe of your /dev/dri/renderD* nodes - you select the actual device you want (e.g. the Arc). • Leave it on "Auto" (the default) and nothing changes - single-GPU setups and anyone who never touches the setting are completely unaffected. • The picked node is now passed explicitly to both QSV and VAAPI; no container restart needed when you change it. Multi-GPU folks (especially Intel iGPU + Arc): I don't have that hardware here, so this is the build to test it on. If your discrete card now shows up and encodes - great, let me know. If it binds but throws "Current pixel format is unsupported", please post the container log so I can chase it. To revert instantly, just set GPU Device back to Auto. 🟢 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.31.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.30.0 🔭 COMING NEXT • Auto-crop / black-bar removal - optional cropdetect pass to strip letterbox/pillarbox bars during the encode (the Handbrake crop=auto equivalent). Plans can change, but that's what's next on the bench.

Hi @tbal82 Thanks for the kind words, glad it's working well for you! Right now there's no crop option yet: x265-butler doesn't apply any video filter during encoding, so black-bar removal isn't available in the current release. Good news though, your request put this on the roadmap. The exact Handbrake crop=auto equivalent (an ffmpeg cropdetect pre-pass that auto-detects the letterbox/pillarbox bars and crops them during the encode) is now planned as a dedicated feature, prompted directly by your post, with an operator on/off toggle in Settings so it stays opt-in. Your use case (letterboxed sources) is exactly what it's aimed at. I'll post here once it ships in a release. Thanks for the suggestion, keep them coming!

🚀 v2.30.0 - Storage + Anti-Double-Work is live ghcr.io/masterjb/x265-butler:2.30.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 storage / anti-double-work fixes from your reports: central-sidecar users no longer get their encoded files re-queued, and the 30-day originals-trash can now live on the array instead of clogging the cache pool. 🔁 CENTRAL-SIDECAR RE-QUEUE FIX If you run sidecar_mode=central, the skip-pipeline used to read only the "beside" sidecar, so it was blind to its own central forensics and re-queued already-encoded files. It now reads the central sidecar (with a beside fallback for mode-switchers) - loop protection works again. Backend-only, nothing to configure. 🗑️ CONFIGURABLE TRASH LOCATION New field: Settings → Encoder → Sidecar card → Trash location. • Leave it EMPTY (default) → trash stays on the cache pool exactly as before (byte-identical, one-click revert). • Set an absolute path (e.g. /mnt/user/media-trash on the array) → the 30-day recoverable originals go there instead of clogging your fast cache. Cache→array cross-device moves are handled automatically. The path must be absolute, not a system root, and NOT inside a scanned share (otherwise the watcher would re-ingest the trashed originals - the exact loop this build prevents). A bad/unmounted trash path now fails loud with a clear trash_move_failed error instead of a cryptic encode failure, and in replace-mode your original is left intact. No new settings are required to upgrade - empty trash_path behaves identically to v2.29.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.30.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.29.0 🔭 COMING NEXT Working on multi-GPU device selection for the next release: • Pick which GPU encodes when you have more than one (e.g. an Arc A380 dGPU next to an Intel iGPU) - right now the first render node is always used, so the dGPU never gets picked. • Per-device encoder detection probe + a device picker in onboarding and Settings. • Arc pixel-format deep-fix. Plans can change, but that is the current focus.

@Benni-chan Thanks for the detailed log, that made the root cause easy to spot. What's happening: you have two GPUs in the box (the CPU's iGPU and the Arc A380). x265-butler currently grabs the first render node it finds under /dev/dri (renderD128), which is your iGPU — so detection only ever probes and uses the iGPU. The Arc (renderD129) is never touched. That's also why the log shows "vaapiDevice: /dev/dri/renderD128" and QSV reporting functional: that's the iGPU, not the Arc. There's currently no way to tell the app which GPU to use, so the more powerful Arc just sits idle. The good news: this is a missing feature, not a broken Arc. I've added it to the roadmap (it'll ship as v2.31.0). Rough plan: 1. Enumerate ALL render devices and probe each one separately, so the app can see which encoder works on which GPU — your Arc will show up as its own option instead of being hidden behind the iGPU. 2. Add a GPU/device picker (onboarding + Settings), so you can explicitly select the Arc. The chosen device gets passed through to both QSV (-qsv_device) and VAAPI (-vaapi_device). Default stays "first device found", so single-GPU setups behave exactly as before. 3. If the Arc needs different encoder parameters than the iGPU (the "Current pixel format is unsupported" line hints it might), I'll handle that as part of the same work. One heads-up: I don't have an Arc card here to test on, so once a build is ready I'll need your help confirming it works on real hardware. Before I start planning the details — does this match what you'd expect? Anything specific about your setup I should know (e.g. how many GPUs are passed into the container, and the output of "ls -la /dev/dri" from inside the container)? That last one would help me a lot. Thanks!

🚀 v2.29.0 - Queue Controls + Pagination Fixes is live ghcr.io/masterjb/x265-butler:2.29.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 An operator-QoL release after the clean-running v2.28.0: two queue-control features you asked for, plus three list/pagination fixes. ✨ WHAT CHANGED • Queue pause/resume (pause-after-current) - a new Pause/Resume control on the Queue page. Pausing stops the queue from picking up the NEXT job while the currently running encode finishes normally (it is not aborted - that is what Cancel-all does). Resume restarts dispatch right away. An amber banner shows the paused state. In-memory only, so a container restart clears the pause. • Bulk "Encode Now" on Library multi-selection - select multiple Library rows and queue them all at once. Blocklisted or already-queued items are skipped and reported per-item without blocking the rest. • Queue list no longer goes empty after switching devices/tabs - the pending/scheduled list re-hydrates when the tab regains focus or the live connection reconnects, instead of staying stale until a reload. • Logs page Per-Job tab is now paginated - the list was capped at 50 entries, so with more than 50 jobs you could not reach the current or older log files. Fixed (with out-of-range page clamping). • Trash page pagination now works without a full reload - controls repaint in place, and a stale out-of-range page clamps to the last real page. No new dependencies, no DB migrations, no encode behavior change. 🟢 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.29.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.28.0 🔭 COMING NEXT (v2.30.0) Already in the works for the next release: • Anti-double-work fix for central sidecars - if you run sidecar mode "central", already-encoded files can currently get re-queued because the skip check only looks for the sidecar next to the source file, not in the central folder. The next release teaches the loop-protection to read the central sidecars too, so encoded files stay skipped. • Configurable trash path - the 30-day trash retention currently lives next to your cache, which can park weeks of files on a fast cache SSD/NVMe. v2.30.0 adds a setting to point the trash at your array (or wherever you want) instead.

@rasalf Awesome, thanks for the thorough testing and the report! :D Good news: all three of your nags are fixed in v2.28.0, which just went live: ghcr.io/masterjb/x265-butler:2.28.0 (and :latest) docker pull ghcr.io/masterjb/x265-butler:latest && docker restart x265-butler 1) "-tag:v hvc1" for macOS compatibility Done. HEVC in .mp4 now carries the hvc1 codec tag instead of ffmpeg's default hev1, so QuickTime and Photos play it. Applies to every encoder; .mkv is unchanged (Matroska ignores the fourcc). 2) Retain the original modification timestamp Done. The encoded file now inherits the source file's modified (and accessed) time instead of getting a fresh "now" timestamp, so sort-by-date and Sonarr/Radarr import logic see it at its real age. It's best-effort: if the timestamp can't be copied the encode still finishes and just logs it. (Note: birth/creation time can't be set on Linux, so it's mtime+atime only.) 3) Bench "Verify on full file" status bar on a 2nd verify Fixed. Running a second verify on a different preset now shows the live progress card right away, Cancel/Retry act on the verify that's actually running, and "Apply as default" comes back without a page reload. On your question about wmv (or any other source container): The output container follows your "match source" setting only for formats that are actually mp4-family (.mp4 / .m4v stay .mp4). Everything else, wmv included, goes to .mkv. That's deliberate: wmv typically carries wmav2 audio, which isn't valid in an mp4 container but is perfectly fine in mkv, so you get a clean remux without an audio re-encode surprise. Short version: wmv in -> mkv out. Let me know how it runs on your UHD 770. Thanks again!

🚀 v2.28.0 - output compatibility + bench fixes is live ghcr.io/masterjb/x265-butler:2.28.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 Three operator-reported papercuts fixed this round. ✅ MACOS / QUICKTIME HEVC PLAYBACK (.mp4 output) HEVC inside .mp4 now carries the hvc1 codec tag instead of ffmpeg's default hev1, which Apple QuickTime and Photos refuse to play. An .mp4 that worked in VLC but was dead on a Mac now plays. Applies to all encoders; .mkv is unchanged. ✅ ORIGINAL MODIFICATION DATE KEPT ON THE ENCODED FILE The encoded output now inherits the source file's modified/accessed time instead of getting a fresh "now" timestamp - so sort-by-date, "recently added", and Sonarr/Radarr import logic see the file at its real age. Best-effort: if the timestamp can't be copied it's logged and the encode still finishes. ✅ BENCH "VERIFY ON FULL FILE" - LIVE STATUS BAR FOR A 2ND VERIFY Running a second "Verify on full file" on a different preset now shows the live progress card right away, and Cancel/Retry act on the verify that's actually running - no page reload needed. 🟢 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.28.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.27.0

@rasalf your diagnosis was exactly right, and this is the build that fixes it. You nailed it with "the encoder detection tries to run ffmpeg only with the low-power options." That's precisely what was happening: the detection probe ran QSV at a small resolution, ffmpeg/iHD auto-selected the low-power encode path, and on your UHD 770 that path rejects the ICQ ratecontrol the app uses â the exact Selected ratecontrol mode is unsupported -22 (Invalid argument) you saw in your container log. So QSV got gated out and you dropped to libx265, even though your manual baseline test encoded fine. The reason the earlier update didn't help: v2.25.0 fixed the probe frame size (16x16 -> 320x240), but the path selection was a separate, second blocker and that's what's fixed now. v2.27.0 changes detection to probe QSV in two tiers and remember which one works: 1. ICQ on the full-encode path, forced with -low_power 0 this is byte-for-byte your successful baseline command. 2. If that's rejected, fall back to CQP (-q:v), which runs in both paths. Whatever passes is what gets used for real encodes. Your baseline proved tier 1 works on your chip, so you should now detect QSV with full ICQ quality instead of falling back to software. To update: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler Then check the startup log for the encoder_detection_complete line â you want detected=["qsv",...] and activeFromAuto=qsv (instead of the "qsv":"compiled-in-broken" / activeFromAuto=vaapi you had before). If it still drops QSV, paste that line plus the encoder_probe_* lines and I'll dig in â but based on your test matrix, this should have you encoding on hardware. Thanks for the thorough troubleshooting data it's the reason this got fixed precisely instead of guessed at.

🚀 v2.27.0 — QSV ratecontrol path fix + code-quality hardening is live ghcr.io/masterjb/x265-butler:2.27.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 The headline: a follow-up to the v2.25.0 QSV/VAAPI detection fix. v2.25.0 fixed the probe FRAME SIZE (16x16 -> 320x240) and that sorted out most setups, but one operator on an Intel UHD 770 (i5-14500T) was still dropped to software libx265 afterward. Turns out at the probe's small resolution, ffmpeg/iHD auto-selects the LOW-POWER encode path, and that path rejects ICQ ratecontrol (-global_quality) with "Invalid argument" so the probe still failed and QSV was still gated out. v2.25.0 fixed the size; the PATH selection was the last blocker. The fix: detection now probes QSV in two tiers and remembers which one works. First it tries ICQ on the full-encode path (best quality, forced with -low_power 0). If that path rejects it, it falls back to CQP (-q:v), which runs in both the full and the low-power path. Whatever passes is used for real encodes. So full-encode Intel chips keep ICQ quality, and low-power-only chips keep hardware QSV via CQP instead of dropping to libx265. A wrong guess self-corrects at detection on a 1-frame clip, it never reaches a real file encode. No local Intel iGPU on my side — validated by mock plus the reporter's manual ffmpeg matrix on real hardware. If you have a working Intel iGPU that was being dropped to libx265, please confirm it now detects QSV. 🔧 ALSO IN THIS RELEASE - Under-the-hood code-quality sweep across the encode, scan/watch, database, API and settings-UI subsystems, NO user-facing behaviour change. Faster, more resilient internals: bounded-concurrency hashing/probing in the scanner and watcher (DB writes stay sequential), parallelised encoder-detection probes with a per-probe timeout, indexed DB read paths, and hardened React cleanup (no leaked timers / no state updates after unmount). Hot-path changes each ship an env-var revert lever (SCAN_PROBE_CONCURRENCY, WATCH_INGEST_CONCURRENCY) so a bad interaction with your hardware can be neutralised without a redeploy. No new dependencies, no migrations. 🟢 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.27.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.26.0

@rasalf Perfect, that's exactly the data I needed and it's good news. The key signal: your baseline succeeds (the muxing overhead line at the end). That baseline command is byte-for-byte what the app now runs after the QSV fix that shipped in v2.22.0, the offending option was a legacy Intel MSDK flag (look_ahead) that the newer oneVPL/libvpl runtime rejects with exactly the -22 (Invalid argument) / Could not open encoder you hit. We removed it, and your baseline run proves the result works on your i5-14500T / UHD 770. Two things your tests also rule out, which is useful: - Variant A (low-power) is the only one that fails "Selected ratecontrol mode is unsupported". So we must NOT force the low-power path on your chip; the ICQ quality mode the app uses isn't available there. The default (full-encode) path is the right one, and your vainfo confirms VAEntrypointEncSlice for HEVC, so you have full hardware encode. - Variants B and C succeed too, which tells me neither the rate-control mode nor the device-init needs changing. So: no new code needed, the fix is already in the released build. You're most likely still on an image from before v2.22.0. Pull the latest image (ghcr.io/masterjb/x265-butler:latest), recreate the container, and QSV should encode through the app exactly like your baseline test just did. Let me know if it still fails after updating and paste the app's encode log, but based on this, you're set.

@rasalf Thanks for testing, and good that VAAPI is back. The QSV path is separate from VAAPI, so VAAPI working only tells us the GPU and driver access are fine -- it doesn't exercise the QSV runtime at all. The "-22 (Invalid argument) / Could not open encoder before EOF" means ffmpeg rejected the hevc_qsv encoder the moment it tried to open it, before any frame was processed. That's almost always one of three things: your Intel GPU only exposes the low-power HEVC encode path, the ICQ rate-control mode we use isn't supported on your silicon, or the QSV device needs explicit init. I can't tell which from the truncated log, so I need you to run a few quick isolation tests inside the container and paste the results. None of these write a file (-f null -), so they're fast and safe. 1) Confirm the encoder and the HEVC entrypoints your GPU exposes. Run: docker exec -it x265-butler ffmpeg -hide_banner -encoders | grep qsv docker exec -it x265-butler sh -c 'vainfo 2>&1 | grep -iE "HEVC|H265"' In the vainfo output, look for the HEVC encode lines. "VAEntrypointEncSlice" means full encode is available; if you ONLY see "VAEntrypointEncSliceLP" for HEVC, your chip is low-power-only -- that alone explains the failure. 2) Pick any real video file that is visible inside the container and note its path (e.g. something under your mounted media folder). In every command below, replace /path/to/sample.mkv with that real path. 3) Baseline -- this reproduces exactly what the app runs. Run it and paste the FULL output (not just the last lines): docker exec -it x265-butler ffmpeg -hide_banner -y -i /path/to/sample.mkv -c:v hevc_qsv -preset slow -global_quality 24 -an -f null - 4) Variant A -- force the low-power encode path: docker exec -it x265-butler ffmpeg -hide_banner -y -i /path/to/sample.mkv -c:v hevc_qsv -preset slow -global_quality 24 -low_power 1 -an -f null - 5) Variant B -- swap ICQ rate control for constant-QP: docker exec -it x265-butler ffmpeg -hide_banner -y -i /path/to/sample.mkv -c:v hevc_qsv -preset medium -q 24 -an -f null - 6) Variant C -- explicit QSV device init derived from VAAPI (which we know works): docker exec -it x265-butler ffmpeg -hide_banner -y -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device qsv=hw@va -i /path/to/sample.mkv -c:v hevc_qsv -preset medium -global_quality 24 -an -f null - Tell me, for steps 3-6, which ones print "video:... muxing overhead" at the end (success) and which ones fail. Paste the full output of step 3 regardless, and the full output of the FIRST variant that succeeds. Also paste the two lines from step 1 (the qsv encoder line and the HEVC vainfo lines), plus your exact CPU/iGPU model (e.g. "i5-12400" or "N100"). That tells me precisely whether the fix is forcing low-power mode, switching the rate-control mode, or changing how we initialise the QSV device for your hardware -- and I'll ship it in the next build.

🚀 v2.26.0 — code-quality sweep (maintenance release) is live ghcr.io/masterjb/x265-butler:2.26.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 internal housekeeping — a whole-project code-quality sweep across the encode, scan/watch, database, API and settings-UI subsystems. There are NO user-facing behaviour changes: everything is a performance, robustness or readability improvement, each pinned by a behaviour-identical test, with zero new dependencies and zero database migrations. Safe drop-in upgrade from v2.25.0. What you get under the hood: bounded-concurrency hashing/probing in the scanner and watcher, parallelised hardware-encoder detection probes with an explicit timeout, indexed/de-duplicated DB read paths, and tighter React lifecycle cleanup (SSE reconnect + settings forms no longer leak timers or update state after unmount). The two biggest source files (the encode orchestrator and the settings form) were split into focused modules with identical runtime behaviour and identical rendered UI. 🟢 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.26.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.25.0

🚀 v2.25.0 — Encoder probe-size fix + diagnostics QoL is live ghcr.io/masterjb/x265-butler:2.25.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 Special thanks to @rasalf and @Urbies The headline: if you have working Intel QSV or Intel/AMD VAAPI but v2.24.0 still dropped you to software libx265, this is the fix. The encoder-detection probe was testing with a 16x16 frame — too small for hardware HEVC encoders to open — so it failed, the encoder got marked broken, and it was gated out. The probe now uses a 320x240 frame (same as the diagnostics test-encode), and both paths share one constant so they can't drift apart again. No local Intel/AMD iGPU on my side — if you were affected, please confirm it now detects your HW. 🔧 ALSO IN THIS RELEASE • Render-device group hint de-fanged — the amber "fix your group membership" warning + PGID/--group-add suggestion now only fires when a /dev/dri/renderD* node actually fails read/write. Before, a fully working render node whose group just differed from your media group would get a PGID change suggested that could break an otherwise-fine setup. • Library bulk-delete — the selection bar gets a 3rd action, Delete (N), to forget many entries at once instead of one at a time. It's a row-only forget: it removes the database rows but NEVER touches the file on disk — a re-scan re-adds the entry. Entries with an active encode or referenced by a benchmark run are skipped, with a per-entry result. Behind a confirm cooldown. 🟢 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.25.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.24.0

@NetCaptive Thanks for the detailed report. That's exactly the info needed to pin this down. Good news: your hardware and container setup are fine. nvidia-smi sees the GPU inside the container, and ffmpeg -encoders lists hevc_nvenc. The error is not a driver/runtime problem, so don't bother swapping back and forth between the proprietary and open-source drivers. That's the wrong layer. What's happening: the encode fails at the moment NVENC opens the session, with "Could not open encoder before EOF" / error code -22 (Invalid argument). When the probe encode fails like that, x265-butler gates NVENC out and falls back to libx265, which is why libx265 works and NVENC doesn't. My suspicion: the GTX 1650 (the original, non-Super TU117) ships with Volta-generation NVENC, which does NOT support HEVC B-frames. The current ffmpeg build combined with -tune hq enables B-frames automatically, and your card rejects that at encoder-open time, giving -22. (The 1650 Super, 1660, and RTX 20-series use Turing NVENC and don't have this limitation. It's specific to the plain 1650.) Could you confirm this by running these three commands INSIDE the container? They test the encoder directly, one variable at a time. No real file needed, they use a synthetic test pattern. 1) Reproduces the app's exact NVENC settings (expected to FAIL with -22): ffmpeg -hide_banner -f lavfi -i testsrc=size=320x240:rate=30:duration=1 -c:v hevc_nvenc -preset p5 -tune hq -rc constqp -qp 23 -b:v 0 -f null - 2) Same, but forces zero B-frames (expected to SUCCEED if my theory is right): ffmpeg -hide_banner -f lavfi -i testsrc=size=320x240:rate=30:duration=1 -c:v hevc_nvenc -preset p5 -tune hq -bf 0 -rc constqp -qp 23 -b:v 0 -f null - 3) Control, drops -tune hq entirely (likely also SUCCEEDS): ffmpeg -hide_banner -f lavfi -i testsrc=size=320x240:rate=30:duration=1 -c:v hevc_nvenc -preset p5 -rc constqp -qp 23 -b:v 0 -f null - Please paste the full output of all three. A success ends with something like "video:Xkb ... muxing overhead" and no error; a failure repeats the -22 message. If command 2 works while command 1 fails, that confirms the B-frame cause, and I'll ship a fix that forces -bf 0 on the NVENC path so the 1650 (and any other Volta-NVENC card) works out of the box. Setting B-frames to 0 has no quality cost in the constant-QP mode this tool uses.

🚀 v2.24.0 — QSV/VAAPI detection decoupling + UI polish is live ghcr.io/masterjb/x265-butler:2.24.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 a broken Intel QSV runtime was dropping you to software libx265, this release lets the same iGPU fall back to VAAPI instead of losing hardware acceleration entirely. 🔧 WHAT CHANGED • Encoder detection now treats QSV and VAAPI as INDEPENDENT capabilities on the same /dev/dri device. QSV is matched by the iHD driver, VAAPI by VAEntrypointEncSlice. An iHD host now exposes BOTH qsv and vaapi candidates. • The runtime probe-encode gate verifies each candidate on its own, so when QSV is present-but-broken the encoder falls back to VAAPI instead of all the way down to software libx265. The diagnostics page still flags the broken QSV so the fallback never silently hides it. • UI polish: the Library "Encode now" button and the desktop "Clear selection" button are lifted to the 44px touch-target standard (Library + Trash); the Queue two-column layout on wider screens is rebalanced to an equal 50/50 split. No new dependencies, no migrations, no pipeline-format changes. 🟢 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.24.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.23.0

🚀 v2.23.0 — Output Strategy: Sidecar Location + In-Place Replace is live ghcr.io/masterjb/x265-butler:2.23.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 adds two opt-in Output settings for people running Sonarr/Radarr-managed libraries who don't want the "movie.x265.mkv" siblings and "movie.x265.json" sidecars cluttering things up. Defaults are byte-identical to v2.22.x — nothing changes until you opt in. Thanks to the forum request that drove it. 🔧 WHAT CHANGED • Sidecar location is now selectable (Output → Sidecar location): "beside" (default, sidecar next to the file as before), "off" (no sidecar at all), or "central" (sidecars go to a mirrored tree under /config instead of into your media library). "central" works even on a read-only media mount, and the boot orphan-sweep covers it. Anti-double-work is unaffected — the MKV tag + DB hash still stop re-encodes when the sidecar is off or central. • In-place replace (Output → Output mode): "suffix" (default — encode to movie.x265.mkv, leave the original) or "replace" (the encoded file takes the original's name, no .x265 sibling). Replace is built safe: the original is moved to the recoverable trash FIRST and only then is the new file renamed in — a crash mid-commit always leaves a recoverable state, and it NEVER hard-deletes (it always trashes, so there's always a recovery path). Hardlinked sources (Sonarr/Radarr "Use Hardlinks") fall back to suffix automatically and the link is left untouched. Enabling replace needs an explicit confirm in Settings since it's a one-way door, and it applies to FUTURE encodes only — existing .x265.mkv files are not touched. No new dependencies, no migrations. Just pull and restart, then flip the new Output settings if you want them. 🟢 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.23.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.22.0

🚀 v2.22.0 — QSV Restore + Diagnostics Excerpt Fix is live ghcr.io/masterjb/x265-butler:2.22.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 fixes Intel QuickSync (QSV) HEVC encoding, which was broken on v2.20.0. Thanks to the forum report that surfaced it. 🔧 WHAT CHANGED • QSV restored: the QSV profile was still passing the Intel MSDK-only "look_ahead" option, which the current oneVPL/libvpl runtime rejects with "(Invalid argument)". That aborted the encode AND the detection probe, so QSV got gated out and you were pointed at hardware / pass-through problems that weren't real. Removed it, QSV encodes again. libx265 / NVENC / VAAPI are untouched. • Better diagnosis: the manual Test Encode on the /diagnostics page now recognises this whole class of encoder-option rejections and says "the encoder rejected an ffmpeg option, NOT a hardware fault" instead of the misleading "check render group / GPU pass-through" hint. Real hardware faults still keep the hardware hint. EN + DE. • Cleaner failure excerpts: encoder-probe failure snippets on the diagnostics page now strip ffmpeg muxer/progress boilerplate so you see the actual error line. No new dependencies, no migrations, no config changes. Just pull and restart. 🟢 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.22.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.21.0

@Urbies Thanks for the report. First: your chip is AMD (Ryzen 7 5825U, Radeon/Vega). That means QSV and NVENC are Intel/NVIDIA-only and will always show as "missing" on your box — that's expected, not the bug. The path you want is VAAPI (hevc_vaapi) on the Mesa radeonsi driver, and that's exactly the one failing. The diagnostics report truncates the failure to "d argument)", which is the tail of "(Invalid argument)". The important part — which ffmpeg option the AMD driver rejected — got cut off before that. I can't pin the fix without the full line, and I don't have AMD hardware to reproduce, so a few raw pastes from inside the container will let me ship the correct fix instead of guessing. 1) DOES YOUR iGPU EXPOSE HEVC ENCODE AT ALL docker exec x265-butler vainfo --display drm 2>&1 | grep -iE "HEVC|Enc" I want to see a line like "VAProfileHEVCMain : VAEntrypointEncSlice". If HEVC EncSlice is absent, the Mesa build/firmware on your box can't HEVC-encode and no app change helps — we'd know immediately. 2) THE FULL, UNTRUNCATED PROBE ERROR (the deciding one) docker exec x265-butler ffmpeg -hide_banner -loglevel verbose -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc=size=320x240:rate=1:duration=1 -vf format=nv12,hwupload -c:v hevc_vaapi -preset slow -rc_mode CQP -qp 28 -compression_level 1 -frames:v 1 -f null - 2>&1 | tail -40 This is byte-for-byte what the app probe runs. Paste the whole tail — the line ending in "(Invalid argument)" is what I need. 3) MINIMAL BISECT (strips preset + rc_mode + compression_level) docker exec x265-butler ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc=size=320x240:rate=1:duration=1 -vf format=nv12,hwupload -c:v hevc_vaapi -qp 28 -frames:v 1 -f null - 2>&1 | tail -40 If this one succeeds, one of the three options the app adds is what your driver rejects — and I drop it from the AMD path. 4) WHAT YOUR DRIVER ACCEPTS docker exec x265-butler ffmpeg -hide_banner -h encoder=hevc_vaapi 2>&1 | head -60 WHY v2.22.0 fixed a similar problem on the Intel/QSV side (a single bad ffmpeg option the new driver rejected). Yours looks like the same class of bug one encoder over — a VAAPI option AMD's driver won't take — but the truncated log hides which one. Commands 2 and 3 pin it exactly. One more thing, unrelated to the GPU: your report shows /media as readable but NOT writable (EACCES), and your cache path /mnt/cache/x265-butler as not writable. Even once VAAPI works, encodes will fail to write output until those are fixed. Check that your container has write access to the /media share and that the cache path you set in Settings points at a path that's actually mounted writable inside the container. Happy to help with those too once the GPU side is sorted.

Thanks for the detailed report. Before I rebuild anything I need to pin the exact layer, because the fix differs a lot depending on one command. ABOUT THE ldd CHECK The ffmpeg in the image is a BtbN static build. On a static build the oneVPL / libmfx dispatcher is linked into the binary, not loaded as a shared library, so: ldd /usr/local/bin/ffmpeg | grep -iE "mfx|vpl" returns nothing even on a fully working QSV build. ldd only lists dynamic libraries, so that empty result can't tell us whether QSV is compiled in. The build config can. Could you paste the raw output of these? 1) BUILD CONFIG (the deciding line) docker exec x265-butler ffmpeg -hide_banner -buildconf | grep -iE "libvpl|libmfx|vaapi" I want to see --enable-libvpl (new oneVPL API, supports Arc / Core Ultra) vs --enable-libmfx (legacy MediaSDK, no Arc support). They are mutually exclusive. 2) ENCODER REGISTERED? docker exec x265-butler ffmpeg -hide_banner -encoders | grep qsv 3) THE ACTUAL FAILURE (what the app probe runs internally) docker exec x265-butler ffmpeg -loglevel verbose -init_hw_device qsv=hw -f lavfi -i nullsrc=s=64x64 -frames:v 1 -c:v hevc_qsv -f null - 2>&1 | tail -40 4) GPU RUNTIME VIEW docker exec x265-butler vainfo --display drm 2>&1 | head -30 docker exec x265-butler sh -c 'ls -l /dev/dri && getent group render video' 5) HARDWARE / HOST CPU + GPU model (e.g. Core Ultra 7 155H, Arc A770, Arc B580), unRAID version + kernel (uname -r), and your container --device lines. WHY v2.22.0 fixed a different QSV problem one layer up (a bad ffmpeg option). Yours is the runtime/driver layer. If command 1 shows libvpl, the binary is fine and the in-container Intel runtime is probably too old for Arc / Core Ultra, so I bake a newer one (no ffmpeg rebuild). If it shows libmfx, you're right and I switch to a libvpl build. I don't have Arc hardware to reproduce, so your paste is what lets me ship the correct fix instead of guessing. Thanks.

🚀 v2.21.0 — Operator Quality-of-Life is live ghcr.io/masterjb/x265-butler:2.21.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 quality-of-life pass on the rough edges around the encode pipeline — the pipeline itself is unchanged. Four fixes/features: 🟩 VAAPI TEST-ENCODE NO LONGER FAILS WITH A BOGUS -38 The /diagnostics [Run test encode] for VAAPI built its ffmpeg arguments differently from the real encode path, so it could fail with a misleading "Function not implemented (-38)" on hardware that actually works. The test-encode now uses the same codec block as a real job (-vaapi_device + -vf format=nv12,hwupload) — a green test now means a green encode, a red test means a real problem. 📁 CACHE PATH RESOLVES ITSELF The staging cache no longer has to be configured by hand. At boot the app probes /mnt/cache for writability and uses it if present; otherwise it falls back to /config/cache. The effective path AND the reason it was chosen are now shown on /diagnostics and in Settings, and an explicit override still wins. If it falls back to /config/cache you get a space advisory so a small appdata share doesn't silently fill up. 🗑️ FORGET A LIBRARY ENTRY Library rows can now be deleted — a row-only "forget" that drops the database entry without touching any file on disk. Mainly for entries whose source file is already gone (moved/deleted outside the app) that cluttered the list with no way to clear them. 2-step confirm with a 10-second undo, blocked while a job for that file is active. 🧹 CLEAR THE LOG /logs now has a [Clear log] button. It empties the in-memory log buffer via a new DELETE /api/logs endpoint, with a 2-step arm→confirm and no undo — the buffer is in-memory, the wipe is not recoverable. The same buffer also backs the Diagnostics recent-errors, slow-requests and slow-queries views, so the button warns you those are cleared 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.21.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.20.0 🔗 LINKS Source: https://github.com/masterjb/x265-butler Image: https://github.com/users/masterjb/packages/container/package/x265-butler

🎬 x265-butler — what's coming next 🎬 @rasalf @illrigger @ASimpleSomething Hey folks! Big thanks for all the feedback in here 🙏, it's shaping the next updates. Quick preview: 🔜 Next up (v2.21.0) 📁 Smarter cache path, auto-detects /mnt/cache, falls back to /config/cache if needed. Shows you which path it picked (and why). Already set a path? Nothing changes for you. ✅ 🛠️ VAAPI test-encode fix, squashed that annoying "-38" error. 🗑️ Delete library entries, including files gone from disk. 🧹 Clear log button, finally! 😅 💡 Heads up: Intel QSV runtime libs already shipped in v2.20.0, if you were waiting on those, they're live. 🧪 Coming after that, output options 📦 Sidecar handling, keep them beside the video (default), tuck them in a central folder, or turn them off. ♻️ In-place replace (opt-in), replace the original instead of writing a new .x265.mkv. Atomic + original goes to trash. Default stays as-is. 🟢 NVIDIA / NVENC users, your container needs: --runtime=nvidia NVIDIA_VISIBLE_DEVICES=all NVIDIA_DRIVER_CAPABILITIES=compute,video,utility ⚠️ The video cap is mandatory, NVENC won't work without it! More soon, keep the reports coming! 🚀

🚀 v2.20.0 — Encoder-Robustness + Mount-Gate is live ghcr.io/masterjb/x265-butler:2.20.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 release works through the QSV diagnostics report filed against v2.19.0 — the one where Intel QSV died with "Error creating MFX session: -9", the encoder list still claimed "detected: qsv" anyway, and a read-only output mount failed late with a bare /media permission error. Honest status on each: ✅ ROOT CAUSE OF "MFX session: -9" — FIXED The image shipped Intel's iHD VA-driver but NOT the oneVPL MFX runtime that QSV actually links against. That mismatch is precisely what -9 means. The image now bundles the oneVPL GPU-runtime: • libmfx-gen1.2 • libvpl2 • libigfxcmrt7 A CI guard verifies these libraries are present in every build, and /diagnostics now reports the oneVPL runtime state so you can confirm it from inside the container. 🔍 NO MORE FALSE-POSITIVE "detected: qsv" Detection no longer trusts the ffmpeg -encoders capability list alone. At boot each HW encoder runs a 1-frame testsrc probe-encode; an encoder is reported as detected ONLY if that probe exits 0. A codec that parses but can't actually encode is no longer offered to you. Cost is +1–3s per encoder at boot, budget-capped. Escape hatch: set X265_PROBE_ENCODE_DISABLED=1 to revert to parse-only detection for exotic hardware where the probe yields a false negative. Restart required. 🔬 CRYPTIC HW-INIT ERRORS → PLAIN-LANGUAGE DIAGNOSIS A 13-pattern stderr → diagnosis dictionary maps the opaque ffmpeg HW-init failures to a cause + next step, surfaced directly under the failed [Run test encode] result (EN + DE). No more pasting -9 into a search engine. 🧮 CPU / iGPU GENERATION ADVISORY /proc/cpuinfo is matched against an embedded Intel gen-table — HEVC-QSV needs Skylake (gen 6)+, 10-bit needs Kaby Lake (gen 7)+. On older silicon the onboarding wizard now recommends the libx265 software fallback instead of letting you pick a QSV path the hardware can't deliver. Advisory only, no hard gate. 🔑 RENDER-NODE PERMISSION EVIDENCE /diagnostics now reports, per /dev/dri/renderD\* device, its owning GID, whether the container process is a member, and whether it has read/write from the container's point of view — so a missing --group-add shows up as evidence, not a guess. 📁 OUTPUT-MOUNT WRITABLE-GATE IN ONBOARDING The setup wizard now probes the chosen output path for writability AT THE CONTINUE STEP, not at the first encode. A non-writable path raises an amber warning with an override checkbox — no more late /media EACCES after setup is already done. 🟩 NVIDIA NVENC ONBOARDING HINT + COPY-BLOCK FIX If the wizard finds no usable GPU but you actually run an NVIDIA card, the software-encoding step now shows the exact 3 container settings, each with its own copy button. This also fixes a live bug: the old copy-block shipped "--runtime=nvidia --gpus all" — --gpus all is compose/CLI syntax (not unRAID-native) and the two mandatory env-vars were missing. Each value now copies into the correct unRAID field (Extra Parameters vs. the two-input Variable form — Name and Value copy separately). 🟢 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.20.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.19.0 If you've got Intel QSV hardware, a [Run test encode] + [Copy report] from /diagnostics after upgrading is the confirmation I'm after — I verified the runtime libs inside the container, but the report tells me your silicon actually encodes.

Thanks for digging into this — your instinct was right that something's off in the media stack, just not quite where it looked. Two things are going on: 1. Your container is still on Bookworm because the image is stale, not because the rebase didn't happen. The published image really is on Debian 13 Trixie now — I just re-checked :latest (digest sha256:93086026…b8b3f678) and it reports Debian GNU/Linux 13 (trixie) with intel-media-va-driver-non-free 25.2.3. Your apt-get update showing bookworm means the running container predates the v2.19.0 pull. Grab the current one first: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler 2. You found a real gap — you're right that components are missing. Even on the correct Trixie image, it ships the iHD VA-API driver but not the oneVPL GPU runtime that QSV/MFX needs — which is exactly why you hit MFX_ERR_DEVICE_FAILED: -9. VA-API works, QSV doesn't, because the runtime backing the MFX session isn't installed. Good catch. This is already queued for the next release (v2.20.0): the image will bake in libmfx-gen1.2, libvpl2, and libigfxcmrt7. Workaround until then (after pulling the Trixie image above): docker exec -u root x265-butler apt-get update docker exec -u root x265-butler apt-get install -y libmfx-gen1.2 libvpl2 libigfxcmrt7 docker restart x265-butler Heads-up: this lives inside the running container, so it gets wiped whenever the container is recreated or auto-updated — treat it as a test to confirm QSV comes alive. The permanent fix is the v2.20.0 image. Two notes on your proposed patch: skip libmfx1 (that's the legacy MediaSDK 1.x runtime — it doesn't support Arc/gen12+; libmfx-gen1.2 is the one you want), and you don't need LIBVA_DRIVER_NAME=iHD — the entrypoint already auto-selects iHD on Intel GPUs via a PCI scan + load-probe, and forcing it would break AMD/older-Intel setups. If you run the workaround, a [Run test encode] report from your Arc card would be hugely helpful to confirm the fix before it ships. 🙏