im really new to this stuff and having trouble with the install its saying sonnar and radarr wont connect to qbittorrent anyone know how to fix that? i think the problem is what i attached but like i said i am dumb and new to this
38 replies
Chris wrote:
Welcome in — and you're not dumb, this one is a known SparkBox bug rather than anything you did. Your attachment didn't come through, so I'm going on your description. Sonarr and Radarr sign in to qBittorrent with a password SparkBox wires in for you, and on fresh installs before v1.6.410 that wiring could save a broken one — the apps then report the download client as unavailable forever. Two commands on the box, in this order: sudo sparkbox upgrade sudo sparkbox arr-bootstrap The first brings you to the current release, the second re-wires Sonarr, Radarr, Prowlarr and qBittorrent to each other. Then re-test the download client in Sonarr. Still failing? Paste the exact error and I'll pick it up. — Chris
ogsince97 wrote:
okay let me try that. Also something called sb-nmp keeps failing on sparkbox also idk if thats a problem. I got them to connect to bit i think but seerr is having a problem connecting to jellyfin
ogsince97 wrote:
[Container Egress] [WARN] Container egress check failed — containers cannot reach tomsparkbox.com. What this DOES break: the dashboard's one-click Update button. It downloads from inside a container, so it will fail with 'Could not resolve host: get.tomsparkbox.com'. Optional Pro-tier license activation won't work either. What still works: every bundled app (Jellyfin, Pi-hole, Vaultwarden, etc.), and updating over SSH — that downloads on the host, not through Docker: sudo sparkbox upgrade To fix container egress itself: 1. UFW: grep DEFAULTFORWARDPOLICY /etc/default/ufw (should be ACCEPT) 2. Run: sudo sparkbox repair-network 3. If you have a custom /etc/docker/daemon.json, check its DNS settings. Re-run 'sparkbox doctor' to verify. [Port Conflicts] [WARN] Port 53: in use by non-Docker process LISTEN 0 1000 10.255.255.254:53 0.0.0.0:
Chris wrote:
One urgent thing first, and it isn't your fault: the screenshot on your original post shows your qBittorrent password in plain text where anyone can read it. Rotate it now: sudo sparkbox reset-password qbit sudo sparkbox arr-bootstrap The second command matters — the reset does not re-point Sonarr and Radarr on its own. For Seerr, four fields catch everybody. Hostname: sb-jellyfin-media (host only, no http, no port). Port: 8096. Use SSL: leave unticked. Username: the one you chose in Jellyfin's own setup screen, not the sparkbox pair. sb-npm is the reverse proxy, and it usually fails because something else already holds port 80 or 443. sudo sparkbox doctor names the culprit. — Chris
Chris wrote:
Picking up the doctor output you posted separately — it changes what I want to see next. That section checks seven ports (53, 80, 443, 8080, 8443, 9000, 9092) and prints a line for every one of them, but your paste only carries the warnings. Send the whole [Port Conflicts] block: the 80 and 443 lines will say outright whether something is holding them, and that is what explains sb-npm. The egress warning is a separate thing and does not block anything I already sent you — an SSH upgrade downloads on the host, not through Docker. To clear it: sudo sparkbox repair-network It takes your apps down for a minute while it rebuilds the network. — Chris
ogsince97 wrote:
[Port Conflicts] [WARN] Port 53: in use by non-Docker process LISTEN 0 1000 10.255.255.254:53 0.0.0.0: [OK] Port 80: in use (Docker -- likely SparkBox) [OK] Port 443: in use by SparkBox (sb-npm) [OK] Port 8080: available [OK] Port 8443: in use by SparkBox (sb-dashboard) [OK] Port 9000: in use by SparkBox (sb-portainer) [OK] Port 9092: available
ogsince97 wrote:
it looks liek its jsut port 53 idk man im dumb im so new to this
Chris wrote:
You read that output correctly — 53 is the only warning left. That's the right call. Two things follow. First, my port theory for sb-npm was wrong: your own output shows 443 in use by sb-npm, so it is bound and running. Confirm with: sudo sparkbox status That lists every container and the state it is in. Second, port 53 belongs to Pi-hole (the ad blocker), not npm. Something on your host already answers DNS there, so Pi-hole cannot claim it. Nothing else depends on Pi-hole, so Jellyfin, Sonarr, Radarr and qBittorrent are unaffected — safe to leave. Say the word and I will move Pi-hole to a free port. How did Seerr and Jellyfin go? — Chris
ogsince97 wrote:
i got those connected but i havent tried anything since npm keeps giving the unhealthy notification
ogsince97 wrote:
with the status pompt everything says healthy but sb-npm Up About a minute (unhealthy)
Chris wrote:
That detail helps — "Up About a minute" means it had only just restarted when you looked. NPM gets a 30-second grace before its health check starts, then probes every 30 seconds, so give it three or four minutes and run sudo sparkbox status again. Still unhealthy after that? Two, in order: sudo sparkbox doctor It prints an sb-npm section that only appears when npm is unhealthy, and it names the cause. sudo sparkbox logs npm That one follows live — Ctrl-C to quit. Paste the last few lines here. Worth saying plainly: npm only matters for custom domains. Jellyfin, Sonarr, Radarr, qBittorrent and Seerr do not go through it, so nothing you have set up is blocked. — Chris
ogsince97 wrote:
so it keeps failing but the doctor only says this 2 warnings and the log doesnt say anything exept this at the end ❯ Starting backend ... ❯ Starting nginx ... [7/27/2026] [2:20:15 PM] [Global ] › ℹ info Using Sqlite: /data/database.sqlite [7/27/2026] [2:20:15 PM] [Migrate ] › ℹ info Current database version: none [7/27/2026] [2:20:15 PM] [Setup ] › ℹ info Logrotate Timer initialized [7/27/2026] [2:20:15 PM] [Setup ] › ℹ info Logrotate completed. [7/27/2026] [2:20:16 PM] [Global ] › ℹ info IP Ranges fetch is enabled [7/27/2026] [2:20:16 PM] [IP Ranges] › ℹ info Fetching IP Ranges from online services... [7/27/2026] [2:20:16 PM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json then stops without me ending it [Container Egress] [WARN] Container egress check failed — containers cannot reach tomsparkbox.com. What this DOES break: the dashboard's one-click Update button. It downloads from inside a container, so it will fail with 'Could not resolve host: get.tomsparkbox.com'. Optional Pro-tier license activation won't work either. What still works: every bundled app (Jellyfin, Pi-hole, Vaultwarden, etc.), and updating over SSH — that downloads on the host, not through Docker: sudo sparkbox upgrade To fix container egress itself: 1. UFW: grep DEFAULTFORWARDPOLICY /etc/default/ufw (should be ACCEPT) 2. Run: sudo sparkbox repair-network 3. If you have a custom /etc/docker/daemon.json, check its DNS settings. Re-run 'sparkbox doctor' to verify. [Port Conflicts] [WARN] Port 53: in use by non-Docker process LISTEN 0 1000 10.255.255.254:53 0.0.0.0: [OK] Port 80: in use (Docker -- likely SparkBox) [OK] Port 443: in use by SparkBox (sb-npm) [OK] Port 8080: available [OK] Port 8443: in use by SparkBox (sb-dashboard) [OK] Port 9000: in use by SparkBox (sb-portainer) [OK] Port 9092: available
Chris wrote:
Those two warnings are one fault, and it explains npm. Your log stops at the IP Ranges fetch — npm waits on that before it finishes booting. Doctor says your containers cannot reach the internet, so it waits forever and the health check never passes. Nothing wrong with npm itself. So we fix egress, not npm. Doctor prints the order: grep DEFAULTFORWARDPOLICY /etc/default/ufw That should say ACCEPT. Then: sudo sparkbox repair-network One question shapes the rest: is SparkBox installed inside Windows (WSL), or on its own Linux box? That 10.255.255.254 holding port 53 is a Windows-side address, and it changes what fixes container DNS. — Chris
ogsince97 wrote:
its on my main pc so windows wsl
Chris wrote:
WSL explains the whole thing, and it is on our side rather than anything you did. That 10.255.255.254 on port 53 is Windows' own resolver, and that same resolver state is what leaves your containers unable to look anything up — which fits your npm log stopping dead at the IP-Ranges fetch. We have this logged as a known open WSL2 issue, and I do not have a verified fix to hand you, so I have flagged your case to Tom rather than guess at one. What it actually costs you: the dashboard's Update button, and npm. Updating over SSH still works — sudo sparkbox upgrade — because that downloads on the host. Everything you got working stays working. — Chris
ogsince97 wrote:
okay last question is their a guide on how to get the jellyfin app onto my tv to link to my server?
Chris wrote:
There is, and the app half is the easy half: search Jellyfin in your TV's app store — it's published for Roku, Fire TV, Apple TV, Android TV, Samsung and LG. It then asks for a server address, in the shape http://192.168.1.50:8096, with your own box's numbers. The snag is the WSL point from earlier. Because SparkBox is running inside Windows, the address it hands out only answers on that PC — there http://localhost:8096 opens Jellyfin fine — but your TV sits on the ordinary network and can't reach it. Bridging that needs a Windows-side step I have no verified command for, so it rides along with what I already put in front of Tom. — Chris
ogsince97 wrote:
brother you have been a huge help thank you! that answers a question anyway looks like the pc is getting hooked up to the tv until payday then ill just buy a second one to run the server
Chris wrote:
Hold off on that second machine — the Windows-side step I owed you landed today, in v1.6.466. Run sudo sparkbox upgrade, then sudo sparkbox urls. It now recognises a WSL address and prints the fix for your own box at the end of the list, so you are reading it off your screen rather than trusting mine. On Windows 11 22H2 or newer it is a small .wslconfig file setting networkingMode=mirrored, a wsl --shutdown, and one firewall command. SparkBox then picks up your PC's ordinary home address and the TV can reach it directly. Windows 10 gets a port-forwarding route instead, also printed. — Chris
tomspark wrote:
Heads up — 1.6.466 just shipped and should cover what you reported here. Grab it with sudo sparkbox upgrade (that is the one that moves you to a new release — update only refreshes app images), and let me know if it's sorted — or if you're still hitting it.
ogsince97 wrote:
Thanks guys! i do have a random question about jellyfin if you guys have an answer i downloaded 4 movies 2 of them work just fine the other 2 like load 3 seconds at a time and dont even load the whole playtime like the other ones and i dont know why i tried using hardware acceleration and it just errors the playback completely for those 2 movies then the other 2 still work fine
Chris wrote:
That split is the clue. The two that play fine are streaming as-is; the other two are in a format the app you're watching in can't take directly, so Jellyfin re-encodes them live — and when it can't keep up you get exactly that stop-start with no full runtime showing. Hardware acceleration erroring only those two fits, because it's only ever used on the re-encoded ones. Put it back first: Settings, Media, Hardware Transcoding, set it to none. Saving that restarts the media apps for you. Then run sudo sparkbox doctor and paste the [Hardware Transcoding] section — it says outright whether your GPU is visible at all from inside WSL. — Chris
ogsince97 wrote:
this is what it says is there something i should do to help the other movies play right? [Hardware Transcoding] [INFO] /dev/dri not found -- Intel/AMD hardware transcoding not available
ogsince97 wrote:
also i dont know if this is important or not but they also dont have the like title picture on them when they dont work
Chris wrote:
That line answers the first half: SparkBox is running inside WSL, and WSL doesn't hand a GPU through as /dev/dri, so there is nothing for Jellyfin to accelerate with. Leave Hardware Transcoding set to none — it can only ever affect the two files being re-encoded, which is why those were the ones that died. The missing artwork is a separate thing, and a useful one. No poster means Jellyfin never identified those files, and that almost always comes down to the raw release filename they arrived with. In Radarr: Settings → Media Management → Show Advanced → enable Rename Movies, so future ones land readable. Paste the two filenames here and I'll read them. — Chris
ogsince97 wrote:
tried the update this is what it said SparkBox] Running in VPS mode [SparkBox] Network profile: private (default-route source IP is private/CGNAT: 172.27.104.69) [SparkBox] Data directory (media/photos/books/manga): /opt/sparkbox/data [SparkBox] Freeing host port 53 for Pi-hole (disabling systemd-resolved stub listener) [SparkBox] Something is still listening on port 53 after disabling the systemd-resolved stub. [SparkBox] Pi-hole may fail to start. Find it with: ss -tulpn | grep ':53' [SparkBox] Detected: Ubuntu 26.04 LTS [SparkBox] Installing system dependencies (detected: debian)... [SparkBox] System dependencies installed (debian). [SparkBox] Package install failed (exit 100). Last 20 lines of pkg-mgr output: W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/resolute-updates/InRelease Connection failed [IP: 172.66.152.176 80] W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/resolute-security/InRelease Connection failed [IP: 172.66.152.176 80] W: Some index files failed to download. They have been ignored, or old ones used instead. E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/a/acl/acl2.3.2-2amd64.deb Connection failed [IP: 104.20.28.246 80] E: Unable to fetch some archives, maybe run apt update or try with --fix-missing? [SparkBox] Full log: /tmp/sb-pkg-756n65.log [SparkBox] Couldn't install 'acl' — media-permission fixes will use chown instead. [SparkBox] Docker already installed: Docker version 29.6.2, build dfc4efb [SparkBox] Docker Compose: 5.3.1 [SparkBox] Existing SparkBox install found (v1.6.475). Upgrading via atomic rename-swap — .env, state/, and module data are preserved. ============================================================ PREFLIGHT — here's what I found on this machine ============================================================ System: Ubuntu 26.04 LTS Hardware: standard Linux server / VPS Memory: 32028 MB Free disk: 845 GB at /opt Install to: /opt/sparkbox Timezone: America/LosAngeles Clock: not checked (no internet reference) Mode: UPGRADE (your settings, data and passwords are kept) ------------------------------------------------------------ ⚠ Port 8443 (SparkBox dashboard) is already in use by: users:(("docker-proxy",pid=115966,fd=8)) ⚠ Port 9000 (Portainer) is already in use by: users:(("docker-proxy",pid=114428,fd=8)) These ports are needed by SparkBox. The install will continue, but the affected service may fail to start until the conflict is resolved. For the dashboard specifically, you can pick another port by setting SBDASHBOARDPORT (e.g. SBDASHBOARDPORT=9443) before installing, or in /opt/sparkbox/.env afterwards followed by 'sudo sparkbox up'. ============================================================ [SparkBox] Downloading SparkBox... curl: (28) Connection timed out after 10002 milliseconds [SparkBox] Verifying release integrity... [SparkBox] Release digest file missing or malformed at https://get.tomsparkbox.com/releases/latest/sparkbox.tar.gz.sha256 [SparkBox] Refusing to install an unverified release. This is a supply-chain safety check.
Chris wrote:
Good news buried in that wall: that is not a failed upgrade. The line just above it — "System dependencies installed (debian)" — is the step that actually matters, and it passed. What died afterwards is one optional extra called acl, and SparkBox is written to treat it exactly that way: it is a helper for permission fixes, and a missing acl is never allowed to stop an otherwise-good install. Your PC simply could not reach Ubuntu's package mirrors at that moment. SparkBox's own download plainly worked, or the installer would not have got that far. To see where you landed: sparkbox version And I am still keen on those two filenames when you get a minute. — Chris
ogsince97 wrote:
how do i get to the file names?
ogsince97 wrote:
Path/data/Movies/The Super Mario Galaxy Movie (2026)/The.Super.Mario.Galaxy.Movie.2026.2160p.UHD.BluRay.REMUX.DV.P7.HDR.MULTi-BTM.mkv this is what it says on jellyfin
Chris wrote:
That filename is the whole answer. 2160p UHD BluRay REMUX is the untouched 4K disc stream — the heaviest format there is — and DV P7 is Dolby Vision that most players cannot take directly. So Jellyfin re-encodes it live, in software, on a box your own doctor showed has no GPU. It cannot keep up, and you get three seconds at a time. Your two working films will be ordinary 1080p. The lever is in Radarr: Settings Profiles, and set Upgrade Until to Bluray-1080p instead of Bluray-2160p Remux. Our own media guide talks you into that 4K upgrade without saying it needs a GPU — that one is on us, and I have logged it. — Chris
ogsince97 wrote:
i have a good gpu how do i add it into the mix?
ogsince97 wrote:
/data/Movies/Backrooms (2026)/Backrooms.2026.2160p.iT.WEB-DL.DDP5.1.Atmos.H.265-RDNYB.mkv this is one that works
Chris wrote:
Good catch — that Backrooms file is 2160p as well, so scratch my line about your two working ones being 1080p. Resolution isn't the divider here; the Dolby Vision REMUX is. That one gets re-encoded live, the Backrooms one streams as-is. On your GPU, the brand decides everything. Doctor's "/dev/dri not found" only rules out Intel and AMD. Nvidia takes a completely different road in SparkBox and is supported — Settings → Media → Hardware Transcoding accepts nvidia — but the host side has to be ready first. Run sudo sparkbox doctor and look for a line mentioning Nvidia. It says whether your card is seen and what's missing. Paste that and I'll take it from there. — Chris
ogsince97 wrote:
[Hardware Transcoding] [INFO] /dev/dri not found -- Intel/AMD hardware transcoding not available doesnt say anything about my nvidia card
Chris wrote:
Nothing about the card is exactly what I needed to see. Doctor only prints an Nvidia line when the driver actually answers on the Linux side — it looks for /dev/nvidia0, /dev/nvidiactl, or a working nvidia-smi. None of those responded, so the box genuinely cannot see your GPU yet, and no Hardware Transcoding setting can change that on its own. One check from that same shell: nvidia-smi -L. If it comes back not-found, the driver isn't reaching your WSL side and that's the thing to sort first. If it does list your card, tell me — the missing piece is then Docker's nvidia runtime, and doctor prints the exact command for it. Fair warning either way: a Dolby Vision P7 REMUX is punishing even for a strong GPU. — Chris
ogsince97 wrote:
this is what that command showed nothing in doctor ~$ nvidia-smi Tue Jul 28 21:14:01 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 610.57.01 KMD Version: 610.88 CUDA UMD Version: 13.3 | +-----------------------------------------+------------------------+----------------------+ | 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 RTX 4070 ... On | 00000000:01:00.0 On | N/A | | 0% 46C P8 16W / 285W | 3191MiB / 16376MiB | 38% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | 0 N/A N/A 34 G /Xwayland N/A | +-----------------------------------------------------------------------------------------+
Chris wrote:
That output is actually good news — the driver is responding and your 4070 is right there. The card isn't the problem. Here's the odd part: doctor looks for exactly what you just ran, so it should have said so. The difference is that doctor runs as root under sudo, and your nvidia-smi ran as you. Two read-only checks from that same shell: sudo nvidia-smi -L docker info --format '{{range $k,$v := .Runtimes}}{{$k}} {{end}}' The first shows whether root can see the card; the second whether Docker has the nvidia runtime, which is the piece Jellyfin actually needs. Paste both and I'll know which half to fix. Worth keeping in mind: a DV P7 REMUX can still outrun even a 4070. — Chris
tomspark wrote:
Heads up — 1.6.496 just shipped and should cover what you reported here. You can grab it straight from the dashboard: Settings → Updates → Update SparkBox. Let me know if that sorts it, or if you're still hitting it. (Prefer the terminal? sudo sparkbox upgrade — note update only refreshes app images and will not move you to a new release.)