Hi, Ive got it all working BUT none of my requests are doing anything, sparkbox doctor looks all ok, is there somewhere else I should be looking to see what is happening?
11 replies
tomspark wrote:
Glad you're up and running on the Pi! The usual reason requests just sit there on a fresh setup is that there are no indexers added yet — SparkBox ships without any (they're a personal choice), so the search apps have nowhere to look and your requests quietly find nothing. Open Prowlarr from your dashboard, go to Indexers, and if that list is empty, add one. Prowlarr automatically shares it with Sonarr and Radarr, and then requests start finding and downloading. Quick way to confirm that's the cause: in Radarr, open a movie and hit the manual search (the magnifying glass). If it finds nothing, it's the missing indexer. Add one and try again — let me know how it goes.
AntoxicDWA wrote:
I actually have the same issue. My indexer is finding them though but it’s getting to qbittorrent but all of the torrents are sitting in “stalled” status. I have no clue what’s wrong
tomspark wrote:
Different beast from blondini's one (his was no indexers), but a common one. 'Stalled' means qBittorrent got the torrent but can't actually connect out to peers to pull the data — and on SparkBox that's almost always the VPN layer, because qBittorrent is locked to run through the VPN. If the tunnel's only half-up, or has no incoming port, downloads just sit there. Two things to check: 1) Is the VPN showing connected/healthy on your dashboard? If it's down, the safety kill-switch stalls everything by design. 2) The usual culprit: port forwarding. Without an incoming port from your VPN, peers can't reach you and torrents stall. Quick tell: open qBittorrent and look at the status bar along the very bottom — if the connection icon is red or says 'firewalled', that's it. Which VPN provider are you using? That decides the fix — some (like Proton) support port forwarding and I can walk you through turning it on; a few don't offer it at all, which would explain the stalls. Tell me which and I'll get you sorted. (And nice — sounds like you're past the earlier setup hurdle!)
AntoxicDWA wrote:
Yup, had a couple roadblocks along the way but Claude helped me through it, mostly around setting up cloudflare tunnels so i can access my apps from public domains. Yup, the connection status is "firewalled" so how would I got about fixing that? I signed up with Surfshark using your affiliate link so thats the VPN provider im using!
tomspark wrote:
Nice work getting through all that — and thanks for using the affiliate link, genuinely appreciated! Honest situation: 'firewalled' on Surfshark is expected, not a bug. Surfshark doesn't offer port forwarding — that's the feature that lets qBittorrent accept incoming connections — so it'll always show firewalled on Surfshark. Nothing you did wrong. The good news: firewalled limits but doesn't kill downloading. You can still pull from people who are seeding; you just can't receive incoming peers. So well-seeded movies and shows should still download (maybe a touch slower) — only rare or low-seed stuff will really struggle or stall. If even popular titles are stuck at zero, let's confirm it's reaching peers: click a stalled torrent in qBittorrent and look at the Trackers and Peers tabs. Seeds showing but nothing moving? Tell me and we'll dig in. Zero seeds? That particular torrent is just dead — try a more popular release. (Honest aside: if torrent speed ever becomes a real pain, VPNs that DO offer port forwarding — Proton's the usual pick — remove the firewalled cap. But plenty of folks run Surfshark happily for well-seeded content, so no need to switch unless it actually bugs you.)
AntoxicDWA wrote:
Below are 2 torrents I have in there and the trackers tab for each, the Peers tab for both are literally completely empty, nothing in it at all
tomspark wrote:
That second screenshot is the real clue — and it's NOT the firewalled thing after all. Look at the tracker list: every single one says 'Host not found' or 'timed out'. That means qBittorrent can't even look up the trackers' addresses — it's a DNS problem inside the VPN. (Your first torrent was trackerless/DHT-only, which is why it looked different, but this one shows what's actually wrong.) DNS not resolving inside the VPN container is a known gremlin, and it's on our side, not yours. Two steps: 1) Quick fix first — restart the VPN so DNS re-establishes: sudo docker restart sb-gluetun Give it a minute (the download apps reconnect to it automatically), then reopen a torrent's Trackers tab. If they flip to 'Working', you're sorted. 2) If they're still 'Host not found' after that, grab the VPN log so I can see the exact DNS error: sudo docker logs sb-gluetun --tail 50 Paste that and I'll point you at the precise setting to fix.
AntoxicDWA wrote:
Nope still not working...here are the logs | └── Restart VPN on healthcheck failure: yes ├── Shadowsocks server settings: | └── Enabled: no ├── HTTP proxy settings: | └── Enabled: no ├── Control server settings: | ├── Listening address: :8000 | ├── Logging: yes | └── Authentication file path: /gluetun/auth/config.toml ├── Storage settings: | └── Filepath: /gluetun/servers.json ├── OS Alpine settings: | ├── Process UID: 1000 | ├── Process GID: 1000 | └── Timezone: america/manaus ├── Public IP settings: | ├── IP file path: /tmp/gluetun/ip | ├── Public IP data base API: ipinfo | └── Public IP data backup APIs: | ├── ifconfigco | ├── ip2location | └── cloudflare └── Version settings: └── Enabled: yes 2026-06-26T20:23:38-04:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.5 and family v4 2026-06-26T20:23:38-04:00 INFO [routing] adding route for 0.0.0.0/0 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed subnets... 2026-06-26T20:23:38-04:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.5 and family v4 2026-06-26T20:23:38-04:00 INFO [routing] adding route for 192.168.0.0/16 2026-06-26T20:23:38-04:00 INFO [routing] adding route for 10.0.0.0/8 2026-06-26T20:23:38-04:00 INFO [routing] adding route for 172.16.0.0/12 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 8989 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 7878 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 9696 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 8686 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 8080 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 8191 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [firewall] setting allowed input port 6767 through interface eth0... 2026-06-26T20:23:38-04:00 INFO [dns] using plaintext DNS at address 1.1.1.1 2026-06-26T20:23:38-04:00 INFO [healthcheck] listening on 127.0.0.1:9999 2026-06-26T20:23:38-04:00 INFO [http server] http server listening on [::]:8000 2026-06-26T20:23:38-04:00 INFO [firewall] allowing VPN connection... 2026-06-26T20:23:38-04:00 INFO [wireguard] Using available kernelspace implementation 2026-06-26T20:23:38-04:00 INFO [wireguard] Connecting to 43.225.189.116:51820 2026-06-26T20:23:38-04:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-06-26T20:23:38-04:00 INFO [dns] downloading hostnames and IP block lists 2026-06-26T20:23:38-04:00 INFO [dns] DNS server listening on [::]:53 2026-06-26T20:23:38-04:00 INFO [dns] ready 2026-06-26T20:23:39-04:00 INFO [ip getter] Public IP address is 43.225.189.117 (United States, Massachusetts, Boston - source: ipinfo+ifconfig.co+ip2location+cloudflare) 2026-06-26T20:23:39-04:00 INFO [vpn] You are running the latest release v3.41.1
tomspark wrote:
Actually that log is good news — and it corrects my last guess, which I owe you. Your VPN is working perfectly: it connected, you've got a real public IP (Boston), and DNS came up fine on 1.1.1.1. So it is NOT a VPN/DNS outage like I thought. So, re-reading those two torrents with fresh eyes: - Torrent 1 was trackerless (only DHT) — pure peer-gossip. - Torrent 2's trackers are mostly the usual dead public trackers; 'host not found / timed out' on those stale lists is normal, not your setup. With no live trackers AND being firewalled (Surfshark = no port forwarding), DHT can't pick up the slack, so you land on zero peers. Most likely those two specific releases are just poorly-seeded or dead. Let's prove it with one clean test — download the Ubuntu Linux ISO torrent straight from ubuntu.com (thousands of seeders, live trackers): - If it downloads, your whole stack is fine and those two were just bad picks — grab better-seeded releases / a stronger indexer. - If even Ubuntu sits at zero peers, then there IS a deeper issue and we'll dig in (I'll have you run a quick DNS check inside the container). Give Ubuntu a go and tell me which way it lands.
AntoxicDWA wrote:
I think it was the indexers and how my minimum seeders was set, it was defaulted to 1, also was using 1337x and it seems like its down so it was a combo of both I'd guess
tomspark wrote:
That'll do it — nice detective work. 1337x has been flaky/down lately, and a minimum-seeders of 1 lets near-dead torrents slip through that then just stall. So it was exactly the combo you spotted, and your actual SparkBox stack is healthy. Two quick things to make it solid going forward: 1) Bump minimum seeders: in Sonarr/Radarr go to Settings - Indexers, click your indexer, hit 'Show Advanced', and set Minimum Seeders to something like 5-10. That auto-filters out the dead/stalling releases. 2) Add a couple more indexers in Prowlarr so you're never reliant on one being up — when 1337x is down, the others still find releases, and Prowlarr syncs them to Sonarr/Radarr automatically. Glad it's sorted — you're properly up and running now! Nice work pushing through all of it.