My question: ls: cannot access '/dev/dxg': No such file or directory ls: cannot access '/usr/lib/wsl/lib': No such file or directory /dev/dri: total 0 crw-rw---- 1 root video 226, 0 Oct 18 10:23 card0 crw-rw---- 1 root 992 226, 128 Oct 18 10:23 renderD128 SparkBox AI replied: The RX580 works on the host but not in Jellyfin's container, so Jellyfin can't use it on this box. The host's D3D12 driver reaches the card through /dev/dxg and the WSL libraries in /usr/lib/wsl/lib. Neither exists inside sb-jellyfin-media. The /dev/dri nodes are there, but on WSL that's not enough for the card to answer. So Jellyfin gets no hardware decode or encode here. Practical steps: - Leave Jellyfin's hardware acceleration set to None. If you turned on VA-API, turn it off. A driver that can't reach the card can make transcodes fail instead of falling back. - Don't hand-patch the container. Adding /dev/dxg and the WSL libraries by hand means a compose override that points outside the folders SparkBox allows for overrides. SparkBox skips that override unless SBCUSTOMALLOWDANGEROUS=1 is set, and I haven't verified it would work anyway. - Expect software transcoding on WSL for now. Direct-play is still your cheapest win. The real fix is for SparkBox to pass the WSL GPU pieces into the media container. That's a change on our side, not s …(cut here — the full chat went to Tom) What I still need help with: (describe what didn't work or what's still broken) RX580 transcoding ls: cannot access '/dev/dxg': No such file or directory ls: cannot access '/usr/lib/wsl/lib': No such file or directory /dev/dri: total 0 crw-rw---- 1 root video 226, 0 Oct 18 10:23 card0 crw-rw---- 1 root 992 226, 128 Oct 18 10:23 renderD128
9 replies
Chris wrote:
Thanks for the detail, Jahemoto, and I'm sorry: the earlier answer named WSL details (a /dev/dxg device, the WSL library folder, and an SBCUSTOMALLOWDANGEROUS setting) that I can't confirm in SparkBox's code. Please set those aside and don't add anything to the Jellyfin container by hand. I've logged this so the team can review it. What I can confirm: SparkBox passes a GPU to Jellyfin through /dev/dri when Hardware Transcoding is set to a GPU option. Your listing shows card0 and renderD128, so the next check is whether the Jellyfin container actually got them. Run this and tell me what it prints: sudo docker exec sb-jellyfin-media ls -l /dev/dri If card0 and renderD128 are listed, the card reached Jellyfin. If it says "No such file or directory", SparkBox did not hand the GPU over. I can't confirm whether an RX580 can encode through /dev/dri on WSL2. Until that's known, if videos that need converting fail to play, set Hardware Transcoding to None. Direct-play titles keep working. Which SparkBox version does your dashboard show?
Jahemoto wrote:
total 0 crw-rw---- 1 root video 226, 0 Oct 18 10:23 card0 crw-rw---- 1 root 992 226, 128 Oct 18 10:23 renderD128 Sparkbox version 3 - latest update
Chris wrote:
Sorry, Jahemoto. My last reply said I couldn't confirm the names from the earlier answer, and that was wrong: the override setting and the /dev/dxg path both exist in SparkBox. The override setting only unlocks risky container entries such as device lists, privileged mode and host networking. The /dev/dxg route is how SparkBox gives an NVIDIA card to Jellyfin on WSL2. Neither gives an AMD card to Jellyfin, so please don't set the override or add anything to the Jellyfin container by hand. What the assistant knows about this has been corrected so it does not repeat it. Your listing shows the card's device nodes, but not whether they reached Jellyfin. Run this one command and paste what it prints: sudo docker exec sb-jellyfin-media ls -l /dev/dri If card0 and renderD128 are listed, the card reached Jellyfin and the problem is past SparkBox, in Jellyfin's setting or the driver. If it says no such file or directory, SparkBox did not pass the card through. Two things would narrow it down: is this Docker Desktop on Windows, Docker inside a WSL Linux distro, or a Linux box or NAS? And which SparkBox release number do you run? Version 3 doesn't tell me the release; I need the three-part number, like 1.6.x.
Jahemoto wrote:
Docker inside a WSL Linux distro total 0 crw-rw---- 1 root video 226, 0 Oct 18 10:23 card0 crw-rw---- 1 root 992 226, 128 Oct 18 10:23 renderD128
Chris wrote:
I'm sorry, Jahemoto. My last reply said SparkBox cannot give an AMD card to Jellyfin, and that was wrong. When Hardware Transcoding is set to a GPU option, SparkBox passes /dev/dri into Jellyfin whenever the box has it, and that covers AMD and Intel cards on Linux. The /dev/dxg route is how an NVIDIA card reaches a container on WSL2. Your listing has no /dev/dxg, so that route probably doesn't apply to your box. My earlier note that the assistant's answer had already been corrected was also premature. I've logged it with the team, and the fix is not in yet. Please run this one check and paste what it prints: sudo docker exec sb-jellyfin-media ls -l /dev/dri If card0 and renderD128 are listed, the card reached Jellyfin, and the next question is whether Jellyfin can encode with it. If it says no such file or directory, SparkBox did not pass the card through, and that tells us where to look next. Until then, please don't add devices or settings to the Jellyfin container by hand.
Jahemoto wrote:
total 0 crw-rw---- 1 root video 226, 0 Oct 18 10:23 card0 crw-rw---- 1 root 992 226, 128 Oct 18 10:23 renderD128
Chris wrote:
Thanks, Jahemoto, that's the check I needed. I'm sorry this thread has gone back and forth so much. Some of my replies here were wrong, and I've logged those wrong WSL details with the team so the assistant stops repeating them. Your container has the card's device nodes, so SparkBox did hand the RX580 to Jellyfin. What I can't confirm is whether Jellyfin can encode with it on WSL2. One next check: play a video that needs converting (one your TV or phone can't play directly) and tell me whether it plays, stutters, or fails. If it fails, set Hardware Transcoding to None. Direct-play titles keep working either way.
Jahemoto wrote:
direct-play stops after 5 minutes of play, probably buffering
Chris wrote:
Thanks for the update, Jahemoto. Stalling after about five minutes is a separate problem from the GPU question, and I don't know its cause yet. One check: play the same title on a second device on the same network. If it also stalls at about five minutes, the problem is on the server side. If it plays through, the first device or its connection is the likely cause. Tell me which one happens.