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.

Edited May 21May 21 by Human-126094

Hello, I don't understand why he doesn't want to take my librarie.

 

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

I got most of the app configured and I show an AppleTV as configured and added but when I click go to watch I get "No available clients found." I try readding again and I get the same error.

 

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.

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 I am currently trying x256-butler, but I don't get the integrated graphics card to detect. I have passed the folder /dev/dri inside the container, with --device /dev/dri and I have tried to set the container as privileged but no luck there

9 hours ago, rasalf said:

Hi I am currently trying x256-butler, but I don't get the integrated graphics card to detect. I have passed the folder /dev/dri inside the container, with --device /dev/dri and I have tried to set the container as privileged but no luck there

I figured this out, the image doesn't have any drivers in it. From the console inside the container, run the following (assuming you are using Intel QuickSync):

sed -i 's/Components: main/Components: main contrib non-free non-free-firmware/g' /etc/apt/sources.list.d/debian.sources

apt-get update

apt-get install -y vainfo intel-media-va-driver-non-free

If you are running Nvidia or AMD, you can throw those into Gemini and ask it to give you the equivalent commands to install the drivers for them.

EDIT: Sorry, I forgot a step:

In your Unraid template for the x265-butler container, add a new Environment Variable:

• Key: LIBVA_DRIVER_NAME

• Value: iHD

Edited May 22May 22 by illrigger
Correction

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 🙏

Edited May 22May 22 by Human-126094
fix spelling

I would try this - but it does concern me that you've locked the source behind a private repo. Not saying you don't have your reasonings, but not being able to see the code is a major red flag.

if i try to scan my media folder i got this message:

404

This page could not be found.

Same here. I get a 404, and Nvidia isn't working. GT1030 card. 580 drivers. I do see it

+-----------------------------------------------------------------------------------------+

| NVIDIA-SMI 580.159.03 Driver Version: 580.159.03 CUDA Version: 13.0 |

+-----------------------------------------+------------------------+----------------------+

| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |

| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |

| | | MIG M. |

|=========================================+========================+======================|

| 0 NVIDIA GeForce GT 1030 Off | 00000000:01:00.0 Off | N/A |

| 50% 29C P8 N/A / 19W | 3MiB / 4096MiB | 0% Default |

| | | N/A |

Are there logs that we can see that would show some of these failures? i cant find one

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.

11 minutes ago, dpackham said:

Are there logs that we can see that would show some of these failures? i cant find one

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.

Hi now I can see the iGPU inside the container but I can't encode any files, in the logs I can see

INFO job transition: encoding→failed {"action":"job_transition","jobId":420,"fileId":396,"transition":"encoding→failed","cause":"statfs_failed:ENOENT","exitCode":0}

And the Benchmark also only works with the software encoder. The hardware encoder just skips everything

# 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

Trying to get this working on Unraid 7.3.0 with an Nvidia 3080 using HVEC. Haven't had any success with the latest update, but I'm also having problems with the page load times. The pages come up pretty quickly, but looking at the dev tools, it'll take around 2 minutes for the root page to load <url>/en/library, <url>/en/dashboard, <url>/en/stats, etc.
During that time, the page is pretty unresponsive.

Once the page loads and I can attempt to force an encode, I'm getting an encode_nonzero_exit
{"level":30,"time":1779555501979,"pid":52,"hostname":"fd0a3db5ee07","requestId":"4a325e91-747e-4cbf-b993-cff51e6bed95","route":"/api/queue","method":"POST","action":"enqueue","jobId":121,"fileId":10,"encoder":"libx265","msg":"job enqueued"}

{"level":30,"time":1779555502784,"pid":52,"hostname":"fd0a3db5ee07","requestId":"e56cc6ad-d4a8-4a7d-8588-cbb52cd33e18","route":"/api/queue","method":"POST","action":"enqueue","jobId":122,"fileId":241,"encoder":"libx265","msg":"job enqueued"}

{"level":30,"time":1779555503502,"pid":52,"hostname":"fd0a3db5ee07","requestId":"6fafe48a-8286-4aa1-8da8-7287abf91d16","route":"/api/queue","method":"POST","action":"enqueue","jobId":123,"fileId":9,"encoder":"libx265","msg":"job enqueued"}

{"level":30,"time":1779555504155,"pid":52,"hostname":"fd0a3db5ee07","requestId":"0600c58b-789f-4a6e-89b2-74380b96c56d","route":"/api/queue","method":"POST","action":"enqueue","jobId":124,"fileId":159,"encoder":"libx265","msg":"job enqueued"}

{"level":30,"time":1779555509454,"pid":52,"hostname":"fd0a3db5ee07","requestId":"181a3761-3274-4f8f-9768-d8bd8e1b0212","route":"/api/queue","method":"POST","action":"enqueue","jobId":125,"fileId":4,"encoder":"libx265","msg":"job enqueued"}

{"level":30,"time":1779555511807,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":120,"fileId":327,"transition":"encoding→failed","cause":"encode_nonzero_exit","exitCode":187,"msg":"job transition: encoding→failed"}

{"level":30,"time":1779555511809,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":121,"fileId":10,"transition":"queued→encoding","encoder":"nvenc","msg":"job transition: queued→encoding"}

{"level":30,"time":1779555511809,"pid":52,"hostname":"fd0a3db5ee07","jobId":121,"encoder":"nvenc","presetResolved":"p5","presetSource":"settings","msg":"dispatch_preset_resolved"}

{"level":30,"time":1779555523811,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":121,"fileId":10,"transition":"encoding→failed","cause":"encode_nonzero_exit","exitCode":187,"msg":"job transition: encoding→failed"}

{"level":30,"time":1779555523814,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":122,"fileId":241,"transition":"queued→encoding","encoder":"nvenc","msg":"job transition: queued→encoding"}

{"level":30,"time":1779555523814,"pid":52,"hostname":"fd0a3db5ee07","jobId":122,"encoder":"nvenc","presetResolved":"p5","presetSource":"settings","msg":"dispatch_preset_resolved"}

{"level":30,"time":1779555534512,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":122,"fileId":241,"transition":"encoding→failed","cause":"encode_nonzero_exit","exitCode":244,"msg":"job transition: encoding→failed"}

{"level":30,"time":1779555534514,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":123,"fileId":9,"transition":"queued→encoding","encoder":"nvenc","msg":"job transition: queued→encoding"}

{"level":30,"time":1779555534515,"pid":52,"hostname":"fd0a3db5ee07","jobId":123,"encoder":"nvenc","presetResolved":"p5","presetSource":"settings","msg":"dispatch_preset_resolved"}

{"level":30,"time":1779555545953,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":123,"fileId":9,"transition":"encoding→failed","cause":"encode_nonzero_exit","exitCode":244,"msg":"job transition: encoding→failed"}

{"level":30,"time":1779555545955,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":124,"fileId":159,"transition":"queued→encoding","encoder":"nvenc","msg":"job transition: queued→encoding"}

{"level":30,"time":1779555545956,"pid":52,"hostname":"fd0a3db5ee07","jobId":124,"encoder":"nvenc","presetResolved":"p5","presetSource":"settings","msg":"dispatch_preset_resolved"}

{"level":40,"time":1779555555181,"pid":52,"hostname":"fd0a3db5ee07","filePath":"/library/All TV/Anime/Scott Pilgrim Takes Off/Season 1/Scott Pilgrim Takes Off - S01E01 - Scott Pilgrim's Precious Little Life WEBDL-1080p.ai.failed","code":1,"stderr":"/library/All TV/Anime/Scott Pilgrim Takes Off/Season 1/Scott Pilgrim Takes Off - S01E01 - Scott Pilgrim's Precious Little Life WEBDL-1080p.ai.failed: Invalid data found when processing input\n","msg":"ffprobe: non-zero exit"}

{"level":30,"time":1779555558057,"pid":52,"hostname":"fd0a3db5ee07","action":"job_transition","jobId":124,"fileId":159,"transition":"encoding→failed","cause":"encode_nonzero_exit","exitCode":187,"msg":"job transition: encoding→failed"}

Lastly, it keeps attempting to re-encode SRT files. I put in a *.srt blocklist wildcard for it but I can still see it logging failures about no video stream.

Edited May 23May 23 by tulathron

QSV on my Arc A380 is still failing, and I think I know why - the container is using a version of GLIBC that's too old to support modern Intel drivers.

I copied the driver over from my working Jellyfin container, and the app stopped recognizing QSV. Looking at the errors, the container looks to be built on Ubuntu 22.10 or Debian 12, which is slightly too old to support Intel DG2 (Arc/Core Ultra). So for this to work, the image would need to be rebased to Debian 13 or Ubuntu 24.04 LTS

3 hours ago, tulathron said:

Trying to get this working on Unraid 7.3.0 with an Nvidia 3080 using HVEC. Haven't had any success with the latest update, but I'm also having problems with the page load times. The pages come up pretty quickly, but looking at the dev tools, it'll take around 2 minutes for the root page to load <url>/en/library, <url>/en/dashboard, <url>/en/stats, etc.
During that time, the page is pretty unresponsive.

Once the page loads and I can attempt to force an encode, I'm getting an ENOENT error.

{"level":30,"time":1779553110447,"pid":52,"hostname":"7468786a39ad","action":"job_transition","jobId":96,"fileId":746,"transition":"queued→encoding","encoder":"nvenc","msg":"job transition: queued→encoding"}

{"level":30,"time":1779553110447,"pid":52,"hostname":"7468786a39ad","jobId":96,"encoder":"nvenc","presetResolved":"p5","presetSource":"settings","msg":"dispatch_preset_resolved"}

{"level":30,"time":1779553110449,"pid":52,"hostname":"7468786a39ad","action":"job_transition","jobId":96,"fileId":746,"transition":"encoding→failed","cause":"statfs_failed:ENOENT","exitCode":0,"msg":"job transition: encoding→failed"}

Lastly, it keeps attempting to re-encode SRT files. I put in a *.srt blocklist wildcard for it but I can still see it logging failures about no video stream.

@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.

3 hours ago, illrigger said:

QSV on my Arc A380 is still failing, and I think I know why - the container is using a version of GLIBC that's too old to support modern Intel drivers.

I copied the driver over from my working Jellyfin container, and the app stopped recognizing QSV. Looking at the errors, the container looks to be built on Ubuntu 22.10 or Debian 12, which is slightly too old to support Intel DG2 (Arc/Core Ultra). So for this to work, the image would need to be rebased to Debian 13 or Ubuntu 24.04 LTS

@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.

🚀 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).

1. New /diagnostics page (sidebar → Wrench icon, between Settings and Logs).
   Seven sections: App + Runtime, Mounts, Devices, Encoders, Warnings, Recent Errors, Onboarding.

2. [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.

3. [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.

4. [Refresh detection]
   after you add --gpus all / --device /dev/dri and restart, this clears the encoder cache without a second restart.

5. Sticky Topbar Warnings Banner
   mount / onboarding / aggregator warnings surface on every page. Per-code 24h-dismiss.

6. 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.

## x265-butler diagnostics report

### App

- version: 2.18.0

- gitHash: c4d25425

- committedAt: 1779567469

- committedAtCET: 23.05.26, 22:17:49

### Runtime

- nodeVersion: v22.22.3

- platform: linux

- arch: x64

- uptimeSec: 364

- pid: 7

### Mounts

| path | readable | writable | error |

|---|---|---|---|

| /media | ✓ | ✗ | EACCES |

| /cache | ✓ | ✓ | |

| /config | ✓ | ✓ | |

### Devices

- DRI: /dev/dri/card0, /dev/dri/renderD128

- NVIDIA: none

### Encoders

- detected: qsv, libx265

- detection warnings: none

### Active warnings

- ERROR mount:EACCES — /media readable=true writable=false error=EACCES

### Recent errors (in-memory, last ≤25)

no recent errors

### Onboarding

- completed: ✓

- hasShare: ✓

### Last test-encode (client UAT run)

- outcome: failed

- encoderPicked: hevc_qsv

- durationMs: 26

- exitCode: 171

stderr:

```

Input #0, lavfi, from 'testsrc=size=320x240:rate=1:duration=5':

Duration: N/A, start: 0.000000, bitrate: N/A

Stream #0:0: Video: wrapped_avframe, rgb24, 320x240 [SAR 1:1 DAR 4:3], 1 fps, 1 tbr, 1 tbn

Stream mapping:

Stream #0:0 -> #0:0 (wrapped_avframe (native) -> hevc (hevc_qsv))

Press [q] to stop, [?] for help

[hevc_qsv @ 0x561aaa7491c0] Error creating a MFX session: -9.

[vost#0:0/hevc_qsv @ 0x561aaa748680] [enc:hevc_qsv @ 0x561aaa749100] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.

[vf#0:0 @ 0x561aaa74aa40] Error sending frames to consumers: Unknown error occurred

[vf#0:0 @ 0x561aaa74aa40] Task finished with error code: -1313558101 (Unknown error occurred)

[vf#0:0 @ 0x561aaa74aa40] Terminating thread with return code -1313558101 (Unknown error occurred)

[vost#0:0/hevc_qsv @ 0x561aaa748680] [enc:hevc_qsv @ 0x561aaa749100] Could not open encoder before EOF

[vost#0:0/hevc_qsv @ 0x561aaa748680] Task finished with error code: -22 (Invalid argument)

[vost#0:0/hevc_qsv @ 0x561aaa748680] Terminating thread with return code -22 (Invalid argument)

[out#0/null @ 0x561aaa747ac0] Nothing was written into output file, because at least one of its streams received no packets.

frame= 0 fps=0.0 q=0.0 Lsize= 0KiB time=N/A bitrate=N/A speed=N/A elapsed=0:00:00.00

Conversion failed!

```

Generated 2026-05-24T08:56:25.269Z

It's better, but it's still failing.

It kinda seems like this wasn't a full rebase to Trixie, some of the errors I am seeing point to the driver base not being completely up to date:

root@Server:~# docker exec -it -u root x265-butler apt-get update

Hit:1 http://deb.debian.org/debian bookworm InRelease

Hit:2 http://deb.debian.org/debian bookworm-updates InRelease

I tried patching the running container to test some things, and found some missing components, but hit a wall.

Missing runtime libraries — libmfx-gen1.2 and libigfxcmrt7 are not installed. Without these the MFX session cannot initialize at all (MFX_ERR_DEVICE_FAILED: -9)

iHD driver version too old — Bookworm ships intel-media-va-driver-non-free 23.1.1, which predates reliable Arc support. Attempting to install Intel's current driver (25.2.4) from their Ubuntu repo fails due to libva ABI incompatibility with the Bookworm base

LIBVA_DRIVER_NAME not set — Without ENV LIBVA_DRIVER_NAME=iHD, the VA-API runtime doesn't know to use the iHD driver for Arc hardware

If you can validate the base is fully Debian 13, the following changes need to be put in the dockerfile to get it to work.

RUN apt-get update && apt-get install -y \

libmfx1 \

libmfx-gen1.2 \

libigfxcmrt7 \

intel-media-va-driver-non-free \

libva-drm2 \

libva2

ENV LIBVA_DRIVER_NAME=iHD

The last var can be set client side with a VARIABLE entry, might be a better choice if it steps on AMD

Edited May 24May 24 by illrigger

🚀 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).

Edited May 24May 24 by Human-126094
tag user + add NVIDIA NVENC section