Human-126094

🚀 v2.19.0 — Trixie base rebase + the Phase 22 bug-fix bundle is live ghcr.io/masterjb/x265-butler:2.19.0 and :latest are up. amd64-only image, now on a Debian 13 (Trixie) base. Pull / upgrade: docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler This is the release that works through the reports @tulathron and @illrigger r filed against v2.18.0. Honest status on each: ✅ INTEL ARC A380 / DG2 QSV ( @illrigger r ) — FIXED The base is rebased Bookworm → Debian 13 (Trixie), which brings the modern Intel media stack in out of the box: • intel-media-va-driver-non-free → 25.2.3 (was a pre-A380-stable iHD) • GLIBC → 2.41 • libva → 2.22 • libdrm → 2.4.124 That's the layer your diagnosis pointed at — the old image's GLIBC + iHD predated the A380 ABI expectations, which is why a hand-dropped Jellyfin driver was needed. No more workaround: Arc-Alchemist / Battlemage / Lunar-Lake HEVC + AV1 encode are in supported range now. If you can run [Run test encode] on your A380 and paste the report, that's the last confirmation I'm after — I verified the driver versions inside the container, but I don't have A380 silicon here to confirm an actual hardware encode. ✅ statfs_failed:ENOENT ON ENCODE START ( @tulathron ) — FIXED The cryptic ENOENT is gone. Encode dispatch now does a FUSE-safe write-probe (the old check lied on shfs / NFS / CIFS overlays) and reports cache_pool_unavailable:<errno> with the actual offending path instead. And Settings → Paths now rejects a non-writable cache_pool_path at save time (HTTP 400), so you find out immediately rather than at the next encode. ✅ SRT FILES + *.srt BLOCKLIST ( @tulathron ) — SURFACED Quick framing: a *.srt blocklist pattern only does something if a share is actually scanning .srt files — the blocklist is evaluated against what the scanner walks. v2.19.0 now tells you when that's the mismatch instead of leaving you guessing: • Adding *.srt when no share scans .srt now shows an amber warning: "no scanned share covers .srt files… add .srt to a share's extensions in Settings to make this pattern effective." • The /blocklist page has a new "Recent matches" column — per-pattern hit count over the last 50 scan evaluations — so you can see at a glance whether a pattern is doing anything. The matching engine itself is unchanged. If srt files are still being picked up and failing "no video stream", the Recent-matches column + warning will show exactly why — paste that and I'll dig in. 🔬 ~2 MIN INITIAL PAGE-LOAD on /library /dashboard /stats ( @tulathron ) — INSTRUMENTED, FIX IS NEXT Straight answer: this release measures it, it doesn't fix it yet. /diagnostics now has Server-Timing headers, a slowQueries block (23 hot DB queries timed), and a Web-Vitals (TTFB / LCP / INP) block per route. That tells me — and you — exactly which query or fetch is hanging the load event. The actual latency fix is the immediate follow-up and is now data-driven instead of a guess. A [Copy report] from a slow load would pinpoint it. 🟢 NVIDIA NVENC — HOST SETUP (doc clarification, applies to all versions) Not a 2.19.0 code change — documenting it here because it trips people up. 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 nvidia-smi -L detection probe, compute = CUDA filters, video = NVENC itself. Verify: docker exec x265-butler nvidia-smi -L → expect a "GPU 0: ..." line. ♻️ ROLLBACK (first Trixie release — just in case) If v2.19.0 misbehaves on your hardware, roll back to the last Bookworm image: docker stop x265-butler && docker rm x265-butler docker pull ghcr.io/masterjb/x265-butler:2.18.6 docker compose pull && docker compose up -d Under 2 minutes, zero data-loss (no DB migrations this release). 📋 THE BUG-REPORT FLOW (unchanged, still the fastest path) 1. Open /diagnostics → [Run test encode] (5s) 2. [Bug report] → opens this thread + copies a Markdown report to your clipboard 3. Paste here The report now also carries the container-image block (OS / GLIBC / driver versions), so QSV-class issues are diagnosable from one paste. ⏭️ WHAT'S NEXT (v2.20.0, Phase 23) Built on this Trixie baseline: MFX-error → human-hint mapping (Error creating MFX session: -9), render-group GID check on /diagnostics, output-mount writable gate in onboarding, and a probe-encode at detection so "detected: qsv" only shows up when a real 1-frame encode succeeds (kills the false-positive QSV detection).

🚀 v2.18.0 — Self-Diagnostic Surface is live ghcr.io/masterjb/x265-butler:2.18.0 + :latest are up. amd64-only image. docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler What's new This release is all about cutting the bug-report round-trip. @tulathron and @illrigger — your reports above were exactly the situation this surface was built for, and they're what the next release fixes (see "Queued for v2.19.0" below). New /diagnostics page (sidebar → Wrench icon, between Settings and Logs). Seven sections: App + Runtime, Mounts, Devices, Encoders, Warnings, Recent Errors, Onboarding. [Run test encode] synthetic 5-second ffmpeg probe (lavfi testsrc, no file from your library is touched). Hard-mutex, 10s SIGKILL ceiling. Returns encoder + exit code + stdout/stderr tail. [Copy report] + [Bug report] produces a Markdown report ready to paste into this thread. Both are disabled until you've run a test-encode once, that way the report always carries lifecycle evidence (encoder picked, ffmpeg exit, what actually came out) and I can act on it. [Refresh detection] after you add --gpus all / --device /dev/dri and restart, this clears the encoder cache without a second restart. Sticky Topbar Warnings Banner mount / onboarding / aggregator warnings surface on every page. Per-code 24h-dismiss. Heuristic-driven 404 + error pages when something crashes or a stale-cache URL 404s, the page now routes straight to [Diagnostics] + [Bug report] + (if onboarding isn't done) [Start onboarding]. The new bug-report flow 1. Open /diagnostics 2. Click [Run test encode] (wait 5 seconds) 3. Click [Bug report], opens this thread and copies the Markdown report to your clipboard 4. Paste here with Ctrl+V That gives me version, git-hash, encoder detection, mount status, recent errors and a concrete ffmpeg outcome in one block. Much faster turnaround on both ends. Queued for v2.19.0 (Phase 22) All four issues raised above are scheduled and grouped into the next release: - statfs_failed:ENOENT on encode start (@tulathron) . Encoder pre-flight statfs es the input inside the container and gets ENOENT — typically a volume-mount mismatch or the file disappeared between scan and encode. Fix replaces the cryptic ENOENT with an actionable operator message + points at the offending path. Workaround now: check Settings → Paths → cache_pool_path resolves to a real mounted volume inside the container (e.g. /cache/x265-butler if /mnt/cache is mapped to /cache). - ~2 min initial page load on /library, /dashboard, /stats (@tulathron) . Paint is fast but the load event hangs — classic long-running background fetch (probe / library scan) that doesn't block render but does block load. Fix moves the offending fetch off the critical path. - SRT files retried despite *.srt blocklist wildcard (@tulathron) . Wildcard match isn't catching .srt against the path it's tested against, so they keep getting picked up as encode candidates and fail "no video stream". Fix corrects the matching surface. - QSV / Arc A380 (DG2) detection failing on current base image (@illrigger) . You diagnosed it correctly — current image's GLIBC + intel-media-va-driver-non-free stack pre-dates DG2 ABI expectations, which is why dropping a newer driver in from Jellyfin breaks QSV detection. Rebase to Debian 13 (Trixie) is queued; that brings GLIBC + intel-media-va-driver + kernel-ABI forward enough for A380 / Arc / Core Ultra QSV out of the box. This is the M2-closing plan and ships as v2.19.0. Kill-switches (if you want to opt out of any new surface) Set in .env / container env, then restart: - NEXT_PUBLIC_DIAGNOSTICS_BANNER_DISABLED=1 — disables Topbar Warnings Banner - NEXT_PUBLIC_DIAGNOSTICS_COPYREPORT_GATE_DISABLED=1 — Copy/Bug-Report buttons always enabled, no test-encode gate - NEXT_PUBLIC_FEEDBACK_FORUM_URL=... — re-routes the Bug report button if this thread ever moves Thanks for the patience and the precise reports, the next round of bug-fixes is now properly scoped because of them.

@illrigger Thanks, and great diagnosis, you nailed it. The current image is built on a base whose GLIBC + Intel media-driver stack pre-dates DG2 (Arc /Core Ultra) support, which is exactly why dropping in a newer driver from Jellyfin breaks QSV detection: the userspace lib expects a newer GLIBC ABI than the base image provides. Rebase to Debian 13 (trixie) is now queued for the next release. That brings GLIBC, intel-media-va-driver-non-free, and the kernel-ABI expectations forward eough for A380 / Arc / Core Ultra QSV to work out of the box.

@tulathron Thanks for the report, all three issues have been scheduled for the next release. 1. statfs_failed:ENOENT on encode start encoder pre-flight stats the input file inside the container and gets ENOENT. Most likely cause: the file isn't visible at the path the app sees (volume-mount mismatch typical on Unraid), or it disappeared between scan and encode. Fix queued. 2. Slow initial page load (~2 min on /library, /dashboard, /stats) paint is fast but the load event hangs, classic symptom of a long-running background fetch (probe / library scan) that doesn't block render but does block load. Fix queued. 3. SRT files retried despite *.srt blocklist wildcard matching path isn't catching .srt correctly, so they keep getting picked up as encode candidates and fail "no video stream". Fix queued. All three are bundled into the next release.

# x265-butler v2.17.2 — Hotfix: Benchmark Hardware Encoders **Released 2026-05-23** (UTC) ## TL;DR The benchmark pipeline was silently failing every hardware-encoder combo (QSV / VAAPI / NVENC) and reporting them as "skipped" in the UI. Only `libx265` (software) produced real measurements. This release fixes the root cause: `encodeForBench` was bypassing the production codec-block builder and emitting incomplete ffmpeg argv. Three new regression tests guard the spawn argv per encoder. ## Image - Registry: `ghcr.io/masterjb/x265-butler:2.17.2` + `:latest` - Architectures: `linux/amd64` + `linux/arm64` - Anonymous pull: enabled ## Pull / Upgrade ```bash docker pull ghcr.io/masterjb/x265-butler:latest docker restart x265-butler ``` Operators pinning a specific version: switch the Container Repository field to `ghcr.io/masterjb/x265-butler:2.17.2`. Operators on `:latest` need no template change — auto-update on next container pull. ## Fix detail `src/lib/bench/vmaf.ts` `encodeForBench()` previously emitted bare ffmpeg argv: ``` -i <in> -c:v hevc_vaapi -preset slow -qp 23 -an -y <out> ``` VAAPI requires `-vaapi_device /dev/dri/renderD128`, `-vf format=nv12,hwupload`, `-rc_mode CQP`, `-compression_level 1`. QSV requires `-init_hw_device qsv=...`, `-look_ahead 1`, `-look_ahead_depth 40`. NVENC requires `-rc constqp`, `-tune hq`. ffmpeg failed at spawn for every HW combo with "device not initialized" or similar, the orchestrator caught the non-zero exit, `markComboFailed` ran, and the UI showed the combo as skipped. The 11-03 Pass-2 verify code already routed through the production `runEncode` codepath + `buildCodecBlock` registry — same pattern is now applied to Pass-1 sweep AND the `_resolveVmafAnchoredValue` probe loop. `libx265` (software) was unaffected because its codec block has no HW setup requirement. API change in `encodeForBench`: - `encoder: string` (ffmpeg-name) → `encoder: EncoderId` (production-id; callers normalize at the boundary) - `nativeQualityParam` dropped — `buildCodecBlock` owns flag-name dispatch - `nativeQualityValue` renamed to `crf` (the encoder-native quality value) - `vaapiDevice?: string` added for device-path override Regression coverage: - `test_encodeForBench_when_vaapi_passes_codec_block_with_device_and_filter` - `test_encodeForBench_when_qsv_passes_codec_block_with_global_quality` - `test_encodeForBench_when_nvenc_passes_codec_block_with_qp` All 3 inspect spawn argv directly so the production-codec-block args cannot regress silently. Full vitest suite: 3425 pass / 28 skipped. ESLint + Prettier clean. TSC 3 carry-forward (bench-run-detail.test.tsx, pre-existing). ## What you also get if upgrading from `:2.13.0` The CA template default was `:2.13.0` until the v2.16.0 tag-strategy simplification. Operators still on that pin pick up four Milestone-2 closing phases at once when moving to `:2.17.2` / `:latest`: ### v2.15.0 — GPU drivers baked in (Phase 18) - Intel Media VA Driver (non-free), i965, Mesa VA drivers shipped in the image (no host-side driver install needed). - `docker-entrypoint.sh` scans `/sys/class/drm/card*/device/vendor` and sets `LIBVA_DRIVER_NAME=iHD` with a load-probe-then-unset fallback for legacy pre-Gen8 Intel (gen4-7 falls back to runtime autodetect). - `probeNvenc()` widened to distinguish ENOENT vs EXIT_NONZERO vs NO_GPU. - New runtime-derived `warnings` field with 4 codes: `dri_present_no_driver`, `qsv_only_legacy_intel`, `vainfo_binary_missing`, `nvenc_no_runtime`. - Topbar notification bell (cross-page visible) + Settings/Encoder amber warnings badge surface the warnings without operator opt-in. - Wizard `HwAccelStep`: pick Auto / Software / Hardware up-front; Hybrid HW-Defaults route per-encoder. - `LICENSES.md` added with non-free-firmware section. ### v2.16.0 / v2.16.1 — Release-distribution overhaul (Phase 19) - GitFlow-classic: dev branch for plan-close bumps, dev → main merge + annotated tag only at phase-close, atomic via `scripts/phase-close-merge.sh` (post-merge tag creation = tag-on-remote iff merge succeeded). - Docker tag strategy reduced from 4 tags per release to 2 canonical ones: - `:X.Y.Z` (operators pinning exact stability) - `:latest` (operators wanting auto-update across releases) - Dropped: `v$SEMVER`, `:$MAJOR` floating-major, `:$SHORT_SHA`. - Historical tags (`:2.13.0`, `:2.15.0`, etc.) remain pullable — only NEW pushes follow the 2-tag rule. - README + CA template `<Overview>` carry an explicit warning that `:latest` auto-updates across major versions; pin `:X.Y.Z` for stability. - `tests/docs/readme-version.test.ts` drift-prevention vitest guards the docs against the 11-month `:1.5.1` drift class. ### v2.17.0 — Onboarding polish (Phase 20) - Wizard PathsStep auto-skips when settings already configured. - AutoScanAwareness deeplink polish: `#auto-scan-advanced` opens the Collapsible + scrolls past sticky topbar. - EncoderStep: `BenchRecommendationChip` shows the benchmark-derived recommendation; `DetectFailRemediation` walks operators through `--device /dev/dri` / `--gpus all` fixes when detection fails. - QualityStep: `CRFExplainer` tooltip with a 0-51 gradient scale + live marker tracking the current CRF input. - 3 new audit-trail logger events: `benchRecommendationServed`, `crfExplainerOpened`, `autoScanHint.engaged`. - Two operator-controllable kill-switches (set in `.env.production` or container env, restart applies in &lt;30s): - `NEXT_PUBLIC_ONBOARDING_BENCH_CHIP_DISABLED=1` - `NEXT_PUBLIC_ONBOARDING_CRF_EXPLAINER_DISABLED=1` - Zero new npm deps, zero DB migrations, zero `/api` mutations. ## Known issue (operator-side, not code) If job logs show: ``` INFO job transition: encoding→failed cause="statfs_failed:ENOENT" ``` The configured `cache_pool_path` (Settings → Paths) does not exist inside the container. On boot, the encoder loop tries `mkdirSync(stageRoot, { recursive: true })` and warns `cache_pool_mkdir_failed` if the parent path is missing or read-only; per-job `statfsSync` then fails. Fix: set `cache_pool_path` to a path under a volume actually mounted into the container (e.g. `/cache/x265-butler` if `/mnt/cache` is mapped to `/cache`). Verify with: ```bash docker exec x265-butler sh -c 'sqlite3 /config/x265-butler.db "SELECT value FROM setting WHERE key='\''cache_pool_path'\''"' ``` A persistent self-diagnostic surface (`/diagnostics` page + mount-permission self-test + test-encode dry-run) is in scope for Phase 21 (next milestone-closing phase; target `v2.18.0`). ## Tag Annotated git tag `v2.17.2` on dev. Tag is annotated but unsigned (carries forward 05-16 audit S6 decision; signed tags deferred to a future supply-chain phase). ## Deferrals carrying forward - SBOM (syft) + cosign signature + SLSA provenance — supply-chain phase, post-M2. - Formal license-compatibility audit — legal-review phase. - Persistent `diagnostic_event` SQLite table — M3-backlog, deferred from Phase 21 in-memory ring-buffer. ## Links - Source: https://gitlab.com/MisterJB/x265-butler - CA template: https://github.com/masterjb/unraid-templates - Image: https://github.com/users/masterjb/packages/container/package/x265-butler

Thanks for sticking with me on this 🙏 Here's where to grab logs and what to look for. 1. App-side logs (UI) Browse to: http://<unraid-ip>:<port>/en/logs (replace `en` with your locale if different). Filter for `encoder` and copy the lines shown. 2. Container logs (unRAID) - Docker tab → click the **x265-butler** icon → **Logs** - Or via terminal: docker logs x265-butler 2>&1 | grep -iE 'encoder|nvenc|nvidia|libva' Look especially for these two lines emitted at startup: encoder_detection_complete ... detected=[ ... ] encoder_probe_failed ... probe=nvenc cause=ENOENT|EXIT_NONZERO If `detected` only contains `libx265` and you see `encoder_probe_failed probe=nvenc cause=ENOENT`, the container cannot see `nvidia-smi` — host driver is fine, but the container is not getting GPU passthrough. 3. Verify GPU passthrough from inside the container docker exec x265-butler nvidia-smi -L Expected: GPU 0: NVIDIA GeForce GT 1030 (UUID: ...) If this errors with `nvidia-smi: not found` or `could not select device driver`, the container is not wired to the NVIDIA runtime. On unRAID make sure the **Nvidia Driver** plugin is installed and the container's **Extra Parameters** field contains: --runtime=nvidia and the variable `NVIDIA_VISIBLE_DEVICES` is set to the GPU UUID (or `all`). 4. For the 404 Please also post: - the exact URL that returns 404 - the line from container logs at the moment you hit it (filter: `grep -i '404\|not found'`) Paste the output of steps 2 + 3 here and we can pinpoint it. One heads-up on the GT 1030 specifically: its NVENC block is H.264-only with no real HEVC encode support — so even once the container sees the GPU, it won't be usable for x265 transcoding on that card. Worth knowing before you go deep on the passthrough setup.

Thanks for the reports @faxxe71 and @dpackham 🙏 Two separate things going on here: **1. 404 on Media Folder scan** — this looks like a bug on my end, not a config issue. I'll reproduce it locally and get a fix into the next release. **2. NVIDIA GT 1030 not picked up** — same root cause as the Intel issue from the earlier thread: the image doesn't ship with the NVIDIA runtime bits baked in. `nvidia-smi` working on the host is expected; the container needs the NVIDIA Container Toolkit hooks plus the right env vars (`NVIDIA_VISIBLE_DEVICES=all`, `NVIDIA_DRIVER_CAPABILITIES=compute,video,utility`) and `--runtime=nvidia`. I'll bundle proper NVENC support and template defaults into the next release so it works out of the box on unRAID with the NVIDIA driver plugin. Tracking both for the next release. I'll post back here once it's out — appreciate the patience while I sort this.

Thanks @rasalf for the report and huge thanks @illrigger for digging in and posting a working workaround, that's super helpful for anyone hitting this in the meantime. You're right that the current image ships without GPU drivers baked in, so VAAPI/QuickSync (and the NVIDIA/AMD equivalents) won't be detected out of the box. That's clearly a rough edge for a "just install and go" experience, especially since hardware-accelerated transcoding is one of the main reasons people want this kind of tool. I'll take a closer look and aim to address it in the next release. Thanks again to both of you 🙏

x265-butler v2.13.0 — M2 v2.0 Polish + Power shipped 🎉 The x265-butler template is now live in unRAID Community Applications. Install via Apps → search `x265-butler`. What is x265-butler? x265-butler reclaims disk space on unRAID by automatically transcoding video files to HEVC (x265). It scans your library shares for non-x265 files, transcodes them in the background using ffmpeg, tracks results in a dashboard, and never re-encodes the same file twice. Lighter-weight than Tdarr / FileFlows / Unmanic. v2.13.0 highlights (M2 v2.0 Polish + Power — 11 phases shipped) - P7 — Stats + Dashboard - P8 — UI Redesign cross-page - P9 — Release-Eng V2 + Supply-Chain - P10 — Pipeline V2 + Container-Polish (libvmaf bake-in) - P11 — Encoder-Benchmark (Smart-Sampling + Pareto-Frontier) - P12 — Encoder-Profile-Editor + Settings-Polish - P13 — Library Power-User - P14 — Multi-Share Support - P15 — Storage-Analyzer - P16 — Auto-Scan-on-Change (chokidar) - P17 — CA Publication (this release) Full release notes (with details + roadmap): https://github.com/masterjb/unraid-templates/blob/main/x265-butler/RELEASE-NOTES.md Questions / issues / feature ideas → reply to this thread.

Hi @pepbill, I'm happy to help you get your Docker container up and running. However, configuring the Apple TV app and troubleshooting the "No available clients found" error fall outside my expertise. My support is limited to running the Docker container. That said, please ensure the Apple TV app is correctly installed and configured on your Apple TV. Make sure your Apple TV is on the same network as your Docker host, and check your firewall settings to ensure communication between the app and your Apple TV isn't being blocked. If the issue persists, I recommend referring to the Apple TV app's documentation or reaching out to the manufacturer's support team.

That looks like a settings error, unfortunately I can't help you with that. Maybe you can find help on the official GitHub page: https://github.com/sahara101/Movie-Roulette

Support for: Movie-Roulette About: Discover your next movie or TV show effortlessly! Movie-Roulette helps you randomly explore titles across various genres and platforms, offering an easy-to-use and engaging experience. GitHub: https://github.com/sahara101/Movie-Roulette FileGator About: FileGator is a free, open-source, self-hosted web application for managing files and folders. GitHub: https://github.com/filegator/filegator x265-butler About: x265-butler reclaims disk space on unRAID by automatically transcoding video files to HEVC (x265). It scans your library shares for non-x265 files, transcodes them in the background using ffmpeg, tracks results in a dashboard, and never re-encodes the same file twice. Lighter-weight than Tdarr / FileFlows / Unmanic. Docker: https://github.com/users/masterjb/packages/container/package/x265-butler Please post any questions/issues relating to this project in this thread.