My question: These containers need attention on my SparkBox: [movie title 2]-media (stopped). What's wrong and can you fix them? SparkBox AI replied: I ran "Bring the whole stack up (sparkbox up) (runs as an approved repair on your box, up to 10 minutes)", but the verification did not pass. sb-[movie title 2]-media is still unhealthy/down after the restart — it didn't recover. Check its logs (sparkbox logs sb-[movie title 2]-media) for the root cause. What I still need help with: (describe what didn't work or what's still broken)
21 replies
Chris wrote:
Got it — this is an automatic acknowledgment from Chris, your AI support representative. Your post is in the support queue, and we’ll get to it as soon as we can. Legend members receive priority replies. If you’d like faster support while helping fund the project’s goals and continued development, consider becoming a Legend backer. <!-- chris-support-queue-ack:v1 --
Chris wrote:
I'm sorry the earlier restart suggestion didn't get the stopped service running; that failed attempt doesn't tell us what caused it to stop. Before suggesting another step, could you tell me which platform this is (Windows with WSL Docker Engine, Docker Desktop, Linux, or a NAS) and the SparkBox version installed? Please don't run another repair yet.
ManelGT wrote:
Sparkbox v1.6.802 on Docker container on a Proxmox VE machine (Linux Debian...)
Chris wrote:
Thanks—that confirms this is SparkBox 1.6.802 on Debian Linux under Proxmox. Sorry I asked you to confirm the platform and version; you’ve answered that now. Since the earlier stack-up didn’t recover the stopped container, the next useful check is its log, not another repair: on the Proxmox host, run sparkbox logs sb-<container-name (replace the placeholder with that container’s name). This is the documented log command. Please share only the relevant error lines, with any passwords, tokens, IPs, and media or file names removed; stop there and don’t run another repair yet.
ManelGT wrote:
No logs, command result empty
Chris wrote:
Thanks for running it — the empty result is actually the clue, and I'm sorry our tool gave you nothing to go on. The stopped app is Jellyfin (the odd name in your first message came from a privacy-label bug we fixed in 1.6.804; the container is sb-jellyfin-media). When its log is completely empty, Jellyfin never got as far as starting: Docker itself refused to start the container, and Docker keeps that reason outside the app's log, which is why sparkbox logs came back blank. That part is our bug: the next SparkBox update makes sparkbox logs and sparkbox doctor print Docker's reason in this situation instead of nothing. One check for now, on the Proxmox machine where SparkBox runs: sudo docker inspect -f '{{.State.Status}} exit={{.State.ExitCode}} {{.State.Error}}' sb-jellyfin-media It only reads the container's state and changes nothing. Please paste the one line it prints (swap any folder names that contain a film or show title for "a folder"). The usual answers are a port already in use (something else on that machine holding 8096) or a folder or device Jellyfin expects that isn't there; each has a different fix, so please hold off on another repair until we see which one it is.
ManelGT wrote:
root@docker:~ docker inspect -f '{{.State.Status}} exit={{.State.ExitCode}} {{.State.Error}}' sb-jellyfin-media created exit=128 error gathering device information while adding custom device "/dev/dri": no such file or directory root@docker:~ (I already suspected that problem with dev-dri, reading from another user posts...)
Chris wrote:
That output confirms Docker cannot start Jellyfin because its configuration requests /dev/dri, but that device is not present on the Debian host. Please run this read-only check on the Proxmox host itself (not inside a container): ls -ld /dev/dri. Tell me whether it exists and what the command reports; please hold off on another restart or repair until we know whether the host should expose a graphics device.
ManelGT wrote:
root@proxmox-ms-01:~ ls -ld /dev/dri drwxr-xr-x 3 root root 100 Sep 25 02:30 /dev/dri root@proxmox-ms-01:~
Chris wrote:
Thanks — that confirms /dev/dri exists on the Proxmox host. I’m sorry: my previous check treated the host path as the key question, but Docker’s error means the Docker daemon that starts SparkBox cannot see that device path; it does not show that the host lacks a graphics device. Could you clarify whether SparkBox itself is running directly on the Debian/Proxmox host, or inside a separate container/VM? Please don’t restart or rebuild anything while we distinguish those environments.
ManelGT wrote:
Spsrkbox is running containerized in a Docker LXC in Proxmox VE in a Minisforum MS-01 minipc (Intel CPU i9 13000, 96Gb memory, NVME...)
Chris wrote:
Sorry—I had you check whether the Proxmox host had /dev/dri, but your output already confirmed that; I should have focused on the extra Docker LXC boundary. The error says the Docker daemon creating Jellyfin cannot see the device path, even though it exists on the Proxmox host. Since SparkBox runs inside a Docker LXC, the next check is whether /dev/dri is visible inside that LXC: on the Debian environment hosting SparkBox (inside the LXC, not on the Proxmox host), run ls -ld /dev/dri and tell me whether it exists. Please don't change LXC device settings or restart/rebuild anything yet. I've corrected what I know about this device-passthrough case so the earlier host-only check isn't repeated for the next person.
ManelGT wrote:
root@docker:~ ls -ld /dev/dri ls: cannot access '/dev/dri': No such file or directory root@docker:~
Chris wrote:
Sorry—I had you check the Proxmox host even though your earlier output already showed /dev/dri there; that wasn't the right next check. The error and your latest result show /dev/dri is missing inside the Docker LXC where Docker is trying to start Jellyfin, so the device being present on the Proxmox host alone isn't enough. Before suggesting a configuration change, do you want Jellyfin to use hardware transcoding, or is CPU-only transcoding fine? That determines the safe next step. I've corrected what I know about this host-versus-LXC distinction so the earlier host-only check isn't repeated for someone else.
ManelGT wrote:
Cpuld just software transcode (i.e. abstain from trying dev/dri. After all i already have Plex for that...
Chris wrote:
Yes—CPU-only software transcoding is fine. The immediate blocker is that Docker is trying to attach /dev/dri before Jellyfin starts, so changing Jellyfin's own hardware-acceleration setting may not get this container past startup. The published 1.6.805 health-check change does not confirm a fix for this Docker-in-LXC device mapping. Please don't edit the compose configuration or rebuild the stack based on a guess; I don't have a verified supported step to remove that startup request for your setup yet.
Chris wrote:
Following up with that step: we found the cause, and it's our bug, not your setup. Because SparkBox runs inside an LXC, it decided whether Jellyfin gets a graphics device by looking at the Proxmox host's card (your MS-01's iGPU), and then asked Docker for /dev/dri — which the LXC doesn't have, so Docker refuses to start Jellyfin at all. That's also why Jellyfin's own transcoding setting can't help: it never gets that far. Since CPU transcoding is what you want, this switches SparkBox's GPU request off. Run it inside the LXC, as root, where you ran ls: 1. sparkbox set-env JELLYFINHWACCEL none 2. sparkbox restart media jellyfin-media The first line changes only the hardware-transcoding setting; the second recreates just the Jellyfin container. Your library, users and settings are kept. Then docker inspect -f '{{.State.Status}}' sb-jellyfin-media should print running; if it still prints created, paste the same one-line inspect you ran before and stop there. The next SparkBox update fixes the check itself, so an LXC without a GPU passed through is no longer asked for one. And I'm sorry for the back-and-forth on the host-versus-LXC checks along the way.
ManelGT wrote:
I just solved this problem: In proxmox, simply added a passthrough to /dev/dri/renderD128 to docker resources...
Chris wrote:
Thanks for sharing what worked. That fits the failure: the Docker environment inside the LXC couldn't access the graphics device, even though it existed on the Proxmox host. Is Jellyfin now starting after the passthrough? If so, please confirm and we can mark the issue resolved.
ManelGT wrote:
Yes, opens and seems to work fine. Solved.
Chris wrote:
Thanks for confirming Jellyfin opens and is working now. I'm glad the device passthrough resolved the startup problem. If it stops opening again, please reply here and we'll pick it up from there.