Tom AI says (full last message): Yeah, 3 files in the entire DB — that's basically empty. Fresh install state every single time. So the full picture is: - server/ gets recreated on every sparkbox up - Tdarr starts, writes 3 skeleton files, you configure everything - Next update wipes server/ again, back to 3 files - Repeat forever This is definitely a SparkBox bug — the update process shouldn't be touching state directories. Nothing you're doing wrong here. In the meantime, a workaround to at least protect your config between now and a fix: manually back up the DB after configuring Tdarr: cp -r /opt/sparkbox/modules/tdarr/server/Tdarr/ /volume1/sparkbox-data/tdarr/DB-backup Then after an update wipes it, restore before starting Tdarr: sparkbox down tdarr cp -r /volume1/sparkbox-data/tdarr/DB-backup /opt/sparkbox/modules/tdarr/server/Tdarr/ sparkbox up tdarr Not elegant, but it keeps your settings alive until the fix ships. Hit the Share to demox button — paste the timestamp evidence (ls -la /opt/sparkbox/modules/tdarr/ showing server/ always today vs compose files being weeks old, plus find returning 3 files). That's a clean bug report Tom can act on.
7 replies
tomspark wrote:
Hey — TomAI has this right, and it's on us to fix. The update process shouldn't be touching your Tdarr state — that's a SparkBox bug. In the meantime, use the backup workaround above (copying the DB folder before and after updates) to keep your settings safe between now and a fix. We're flagging this for a proper code fix and will post a patch note when it ships.
TestedEcho wrote:
Hey, got this trying the backup thing above, not urgent but just so you know it didnt work... cp -r /opt/sparkbox/modules/tdarr/server/Tdarr/ /volume1/sparkbox-data/tdarr/DB-backup cp : Cannot find path 'C:\opt\sparkbox\modules\tdarr\server\Tdarr\' because it does not exist. At line:1 char:1 + cp -r /opt/sparkbox/modules/tdarr/server/Tdarr/ /volume1/sparkbox-dat ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (C:\opt\sparkbox...r\server\Tdarr\:String) [ Copy-Item], ItemNotFoundException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand
tomspark wrote:
Those commands need to run on your NAS, not on your Windows PC — that error is Windows PowerShell trying to find a Linux path on your local machine, which doesn't exist there. You need to open an SSH session into your NAS first (Windows Terminal or PuTTY: ssh yourname@your-nas-ip), then paste the commands in that window. Also, newer SparkBox versions added a built-in backup tool — from your NAS terminal, run sparkbox restore-tdarr --list to see if any snapshots were saved before the last wipe.
TestedEcho wrote:
sorry, ssh runs out every 2 hours didn't pay enough attention. good feature, when i look at what i'm doing
tomspark wrote:
No worries at all — that trips up a lot of people. You're set either way: from your NAS terminal, sparkbox restore-tdarr --list shows any snapshots SparkBox saved automatically, so if an update ever wipes Tdarr again you can roll it straight back. We're still chasing the root cause so it stops happening in the first place, and I'll post here when that fix lands. Shout if you hit any snags.
TestedEcho wrote:
Thanks for fixing this one!
Chris wrote:
Following up on Tom's promise to post here once the root-cause fix landed — it shipped in v1.6.408 and nobody circled back to tell you, which is on us. The real cause was the upgrade step itself: it carried across the config and data folders but not modules/tdarr/server, where the libraries and flows actually live, so a core upgrade dropped an empty one in and Tdarr booted healthy and blank. sudo sparkbox upgrade closes it. Tdarr also self-restores from its snapshot now if the database is ever corrupted, so restore-tdarr is a backstop rather than your first move. — Chris