Hello, I saw the video on youtube and am highly interested in running this. I've been interested in ARR stacks for a little while but just havent felt confident enough to pull the trigger. With that said, my home server is set up a certain way and Im curious how easy it would be to impliment Sparkbox into my existing infrastructure. Currently I host TrueNAS on one a VM, a seperate VM for torrents and one more for Jellyfin. Using SMB I have the Truenas pool on my torrent VM in a mounted drive. Same on Jellyfin. How easy would it be to have the same setup with Sparkbox? Simple as mounting the drives with cifs like I am currently and pointing a docker file to the storage locations? Would this take much more configuring to pull off? Appreciate any input and thanks in advance!
7 replies
tomspark wrote:
All good — state file shows false now which matches what the code does by default, but with the toggle flipped twice we can't reconstruct the original. Keeping an eye out for other reports; if you ever do a fresh install or upgrade on a separate box and catch it on out of the box, that'd be the gold-standard repro. Thanks for chasing it.
tomspark wrote:
Hey waffle38930 — SparkBox is single-host all-in-one (qBit + arr + Jellyfin all in one Docker stack), so you'd collapse your torrent + Jellyfin VMs into one SparkBox host that mounts the TrueNAS pool. The footgun: SMB/CIFS doesn't support hardlinks, so qBit→arr atomic moves fall back to copying — double disk use on every download. NFS mount (or running SparkBox directly on TrueNAS SCALE) preserves hardlinks. Set MEDIAROOT to that mount path during install and you're set.
waffle38930 wrote:
Hi, thanks for your reply. I pulled the trigger and commited. I created an NFS share and mounted that to my new debian VM hosting SparkBox. I'll let you know how I get on, but its already looking like a fine piece of software. Hats off to you sir.
tomspark wrote:
Right on, glad you pulled the trigger — NFS over SMB was the right call for the arr stack. Yell back if anything trips you up during setup. Quick aside: just shipped v1.6.84 with opt-in error tracking under Settings → Privacy. Off by default; if you flip it on (we're 1-dev / indie / beta), the dashboard sends sanitized crash reports to me when something goes sideways — so I can fix bugs without you having to write a whole post first. Disclosure of exactly what gets sent / never sent is in that section. Totally optional, just helps the beta if you're up for it.
waffle38930 wrote:
I upgraded and went to turn it on, but it was on by default. Not sure if by design as you previously mentioned its Off by default and states so online. Will leave it on anyway for you. Thanks
tomspark wrote:
Huh — that shouldn't happen. The code defaults to off (telemetry.js returns enabled:false when no state file exists, and nothing in install.sh writes one). Two ways to sanity-check: (1) sudo cat /opt/sparkbox/state/telemetry.json — if the file exists with enabled:true, something wrote it and I want to know what; if it's missing, then the toggle is rendering wrong. (2) F12 → Network tab → reload Settings → look at the GET /api/telemetry/settings response. Either path tells me where to look. Thanks for flagging it AND for leaving it on regardless — that's the beta working as intended.
waffle38930 wrote:
It is set to false, however, I can't confirm it was always like that, as I see an "updatedat" parameter, I toggled it off then on again when I saw it :') let me know if you need any more info