Tdarr Recurring Problem Despite Fix
Posted by kiltmann
TomAI Thread: For Tdarr I can't seem to restore my libraries, flows, and variables. This happens whenever there is an overnight update, manual update, or sparkbox upgrade. The following was output when I ran the restore-tdarr command: [INFO] Your previous config is kept at: /opt/sparkbox/state/tdarr-snapshots/.pre-restore-20260720T193448Z but there is nothing in the file. Log window doesn't go back far enough to catch the actual wipe event (it's just quiet plugin-update noise from the healthy run right now) — the container's not currently erroring, so I can't pull the smoking-gun EACCES line from here. Rather than have you hunt through ownership by hand, two things: Can you check the fixed version actually landed on your box: sparkbox version (or check the Updates tab). If you're below v1.6.263, that's your answer straight up — update SparkBox itself and the perms-heal step starts running automatically on future Tdarr up/restarts. If you're already on v1.6.263+ and it's still wiping, that means the heal isn't covering your case (worth flagging, since the fix was supposed to close this). Before I call it a fresh bug, can you paste the output of: ls -la /opt/sparkbox/modules/tdarr/server /opt/sparkbox/modules/tdarr/configs That'll show me if ownership is drifting away from your PUID/PGID again right now, live, instead of guessing at what happened during last night's update. I'm not confident this is fully closed on your box given you're still seeing it — if the version check and ownership dump don't point to something I can fix directly, click Share to demox below so Tom can see this specific recurrence. He'll want the version number for it. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update sparkbox version SparkBox v1.6.406 kiltmann@celestialtraveler:~$ ls -la /opt/sparkbox/modules/tdarr/server /opt/sparkbox/modules/tdarr/configs /opt/sparkbox/modules/tdarr/configs: total 16 drwxr-xr-x 2 kiltmann kiltmann 4096 Jul 20 19:51 . drwxrwxr-x 5 kiltmann kiltmann 4096 Jul 20 19:51 .. -rw-rw-r-- 1 kiltmann kiltmann 489 Jul 20 19:51 TdarrNodeConfig.json -rw-rw-r-- 1 kiltmann kiltmann 409 Jul 20 19:51 TdarrServerConfig.json /opt/sparkbox/modules/tdarr/server: total 20 drwxr-xr-x 3 kiltmann kiltmann 4096 Jul 20 19:31 . drwxrwxr-x 5 kiltmann kiltmann 4096 Jul 20 19:51 .. -rw-r--r-- 1 kiltmann kiltmann 5 Jul 20 19:31 pgid -rw-r--r-- 1 kiltmann kiltmann 5 Jul 20 19:31 puid drwxrwxr-x 8 kiltmann kiltmann 4096 Jul 20 23:51 Tdarr Everything's healthy right now, and the logs are boring — no crash, no perms error, nothing. Which actually tells us something: Tdarr's config DB is fine at boot, it's just empty. That matches your report — the restore snapshot itself had nothing in it, meaning the DB was already empty before the pre-restore snapshot was even taken. That points at the DB file itself, not folder ownership. Tdarr keeps its actual libraries/flows/variables in a DB.json under .../server/Tdarr/Tdarr/DB (LevelDB dir) inside that server/Tdarr tree you listed. Can you check if that DB folder is actually populated right now: find /opt/sparkbox/modules/tdarr/server/Tdarr -maxdepth 4 -iname "DB" That'll tell us if the DB is currently sitting there with data (meaning something during the update process specifically nukes/recreates it before the pre-restore snapshot fires — a sequencing bug in the update script), or if it's empty/missing right now too (meaning it never persisted after your last restore attempt at all). Given the snapshot itself came back empty, I lean toward this being an actual ordering bug in restore-tdarr/the update flow — snapshotting after the wipe instead of before. That's not something I can fix from here with my tools, and it's not a config mistake on your end. Once you paste that find output, I'll have the concrete evidence — worth putting in front of Tom either way since this is the second time this exact class of report has come in. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update find /opt/sparkbox/modules/tdarr/server/Tdarr -maxdepth 4 -iname "DB" /opt/sparkbox/modules/tdarr/server/Tdarr/Plugins/FlowPlugins/CommunityFlowPlugins/handbrake /opt/sparkbox/modules/tdarr/server/Tdarr/Plugins/Community/TdarrPlugin077bHandBrakeNVENC264Configurable.js /opt/sparkbox/modules/tdarr/server/Tdarr/Plugins/Community/TdarrPlugina9hcHaveAGitGatHandBrakeH264Fast1080p30.js /opt/sparkbox/modules/tdarr/server/Tdarr/Plugins/Community/TdarrPlugina8hcHaveAGitGatHandBrakeH264VeryFast1080p30.js /opt/sparkbox/modules/tdarr/server/Tdarr/Plugins/Community/TdarrPlugin00tdactionhandbrakeffmpegcustom.js /opt/sparkbox/modules/tdarr/server/Tdarr/Plugins/Community/TdarrPlugin00tdactionhandbrakebasicoptions.js /opt/sparkbox/modules/tdarr/server/Tdarr/DB2 /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/StagedJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/FileJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/StatisticsJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/SettingsGlobalJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/LibrarySettingsJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/F2FOutputJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/ApiKeysJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/UsersJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/JobsJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/FlowsJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/NodeJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/SQL/database.db-wal /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/SQL/database.db /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/SQL/database.db-shm /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/WorkerVerdictHistoryJSONDB /opt/sparkbox/modules/tdarr/server/Tdarr/DB2/VariablesJSONDB That's the confirmation I needed. There is a live .db / .db-wal / .db-shm set sitting on disk right now — so the DB isn't missing or empty at rest. That's the classic "recreate happened while the DB had an open WAL, or the container got recreated mid-write" signature — SQLite/leveldb-style DBs like that can look totally empty to a fresh Tdarr process if the -wal/-shm files got orphaned from a different DB file (stale checkpoint, or the container came up against a half-flushed WAL from before the update). That's consistent with your report: an update event recreates the Tdarr container, something in that recreate window doesn't let the WAL checkpoint/flush cleanly before Tdarr shuts down, and Tdarr boots clean-but-empty against a DB it can't recover, while the "pre-restore" snapshot happens after that already occurred — so the snapshot faithfully captures... nothing. This isn't a folder-permissions issue (healtdarrperms already covers that case and you're on v1.6.406, well past that fix). This looks like a genuine sequencing/shutdown-ordering bug in the update path specific to Tdarr's DB engine, and it's outside what I can fix with restart/permission tools — a restart right now would just re-trigger the same risk, not recover the old data. I'm not going to guess further or have you hand-edit DB files — that's real risk of making it worse. Click Share to demox below and paste this whole thread (you've already got the ls, the find, and the version). Flag it as recurring on 1.6.406 despite the perms fix — Tom will want the exact WAL/DB filenames from that listing to reproduce it.
2 replies
Chris wrote:
You did everything right here — and thanks for the thorough dump; the version check, the ls, and the find are exactly what's needed. Nothing to worry about with your actual media: this is only Tdarr's little settings database, so your movies and shows are untouched. You've landed on the real problem yourself — you're on the newest version (1.6.406) with the ownership-heal fix already in, and it's still wiping. That means this is a genuine bug in the update/restore sequence, not anything on your end. Please don't hand-edit those DB files; that only risks making things worse. I've flagged it straight to Tom with your version and the exact filenames from your listing — he handles these personally and will want to reproduce it from your evidence. Best to hold off on another restore until he's had a look, since it would just re-trigger the same risk.
Chris wrote:
You can lift that hold — Tom reproduced it and shipped the fix the same day, in v1.6.408. The cause was the upgrade itself, not the restore. Tdarr keeps its libraries, flows and variables in modules/tdarr/server and configs — folders the upgrade didn't preserve, so it moved your live data aside and dropped in the fresh release, which ships those empty. Tdarr then booted healthy and blank, every single time. That is also why your snapshot had nothing in it: the loss happened inside the installer, before the snapshot ever ran. Nothing you did wrong. sudo sparkbox upgrade Honest limit — this protects future upgrades but cannot recover what is already gone. Rebuild your libraries once and that set will stick. — Chris