Hello, I have my NAS mounted to my sparkbox stack. The NAS is on /mnt/media and attached to sparkbox using /data/Media, downloads, torrents etc. TDARR for some reason can only see the files that are inside of sparkbox instead of the mounted NAS. I am not sure how to have it see the mounted media like the rest of the applications like Jellyfin and Seerr can.
19 replies
tomspark wrote:
Good catch — and it's our bug, not your setup. Every other media app (Jellyfin, Seerr, the arr stack) reads your custom media location, but Tdarr was accidentally hardcoded to the built-in folder, so it never looks at your NAS. I've just fixed that in the code and it'll come down in the next update. To unblock you right now: open /opt/sparkbox/modules/tdarr/docker-compose.yml, find the line - ${SBROOT:-/opt/sparkbox}/data/media:/data and change it to - ${MEDIAROOT:-${SBROOT:-/opt/sparkbox}/data/media}:/data then run sudo sparkbox restart tdarr. Point a Tdarr Library at /data and your NAS files will show up. That's the exact fix that's shipping, so the update won't undo it.
gdavidson26 wrote:
Okay so I did that and for some reason it is only showing the preset sparkbox folder's I.E Movies, TV, Downloads, ETC, instead of my actual NAS files. Do I have a setting wrong? I have the media root set in the sparkbox server config to /mnt/media and I have always pointed all my media applications at /data which has always then shown my NAS files.
tomspark wrote:
Good news — the proper fix just shipped in v1.6.177, so you can drop the manual edit. Run sudo sparkbox update, and when it finishes, sudo sparkbox restart tdarr. That swaps your hand-edit for the official one, which points Tdarr at the exact same media location as Jellyfin and the arr apps. Then in Tdarr re-scan the library and it should show your NAS files instead of those empty preset folders. If it STILL shows the built-in Movies/TV/Downloads after that, then your MEDIAROOT isn't actually pointed at the NAS — paste the line from grep MEDIAROOT /opt/sparkbox/.env and I'll get it sorted.
gdavidson26 wrote:
The update fixed the issue. Thanks for the quick fix!
tomspark wrote:
Awesome, glad that sorted it! Tdarr's now reading the exact same NAS location as Jellyfin and the arr apps, so anything you add or transcode lines up across everything. Thanks for flagging it in the first place — that's what got it fixed fast. Shout if anything else comes up.
gdavidson26 wrote:
The only issue I noticed now is that tdarr will not run nvidia transcoding. I have the GPU attached to the VM and sparkbox can see the GPU if I use "nvidia-smi". I also have the drivers updated.
tomspark wrote:
Good news, that one's got a known fix. The key thing: your GPU working with nvidia-smi on the box doesn't mean the containers can use it — Docker needs an extra bridge, and Tdarr needs the GPU handed to it specifically. Let's first see which side it is. Run: sudo docker exec sb-tdarr nvidia-smi If that errors or shows no GPU, the container can't see it yet — the fix is installing the nvidia-container-toolkit plus a small per-app override so it survives updates (I'll give you the exact steps). If it DOES list your GPU, then Tdarr can already see it and we just need to switch on a GPU transcode worker inside Tdarr's settings. Tell me which one you get and I'll take it from there.
gdavidson26 wrote:
It does list my gpu.
tomspark wrote:
Perfect — so the GPU is reachable from inside Tdarr, which means the hard part's already done and it's just Tdarr's own settings now. Two things gate GPU transcoding in Tdarr: 1) GPU workers: on the Tdarr home page, find your node and look at the worker counters — there's a separate "Transcode GPU" one that usually starts at 0. Nudge it up to 1. With 0 GPU workers it only ever uses the CPU. 2) The transcode plugin/flow has to actually call the GPU (an NVENC encoder). A CPU/x265 plugin won't touch the GPU even with a worker free. Set the GPU worker to 1 and run a transcode — if it still goes to CPU, tell me which plugin or flow you're using and I'll point you at the NVENC version.
gdavidson26 wrote:
Okay I have the GPU worker's set to 3 for transcode and 6 for health check. Under my libraries for both my movies and tv I have the plugin order of "Lmg1 Reorder Streams - Migz Transcode using Nvidia GPU & FFMPEG - New File Size Check". I also have the setting under the node options for "Allow GPU workers to do CPU tasks" turned to on.
tomspark wrote:
Ah, that's the tell — your Tdarr setup is actually right, so this is the last sneaky bit. nvidia-smi working only proves the container can SEE the card; actually ENCODING on it (NVENC) needs an extra GPU "capability" that isn't switched on by default, so the Migz Nvidia plugin can't grab the GPU even though everything looks correct. The fix is a small SparkBox override that survives updates. Create /opt/sparkbox/state/overrides/tdarr.yml containing: services: tdarr: runtime: nvidia environment: - NVIDIAVISIBLEDEVICES=all - NVIDIADRIVERCAPABILITIES=all Then run: sudo sparkbox restart tdarr That "all" is what switches on the video/NVENC capability. Run a transcode after and it should hit the GPU. If it still won't, open the transcode log for one file and paste the ffmpeg error — that'll show if NVENC is being rejected.
gdavidson26 wrote:
It still is not working. Here is the error log. 2026-06-03T19:30:49.380Z STATISTICSWRITINGAPP: mkvmerge v73.0.0 ('25 or 6 to 4') 64-bit 60 2026-06-03T19:30:49.380Z STATISTICSWRITINGDATEUTC: 2023-01-17 00:57:36 61 2026-06-03T19:30:49.380Z STATISTICSTAGS: BPS DURATION NUMBEROFFRAMES NUMBEROFBYTES 62 2026-06-03T19:30:49.380Z 63 2026-06-03T19:30:49.380Z Stream mapping: 64 2026-06-03T19:30:49.380Z Stream 0:0 - 0:0 (h264 (native) - hevc (hevcnvenc)) 65 2026-06-03T19:30:49.380Z Stream 0:1 - 0:1 (copy) 66 2026-06-03T19:30:49.380Z Stream 0:2 - 0:2 (copy) 67 2026-06-03T19:30:49.380Z 68 2026-06-03T19:30:49.380Z Press [q] to stop, [?] for help 69 2026-06-03T19:30:49.380Z 70 2026-06-03T19:30:49.380Z [h264 @ 0x635197dc7e00] Cannot load libnvcuvid.so.1 71 2026-06-03T19:30:49.380Z [h264 @ 0x635197dc7e00] Failed loading nvcuvid. 72 2026-06-03T19:30:49.380Z [h264 @ 0x635197dc7e00] Failed setup for format cuda: hwaccel initialisation returned error. 73 2026-06-03T19:30:49.380Z 74 2026-06-03T19:30:49.380Z [hevcnvenc @ 0x635196c84b40] Cannot load libnvidia-encode.so.1 75 2026-06-03T19:30:49.380Z [hevcnvenc @ 0x635196c84b40] The minimum required Nvidia driver for nvenc is 520.56.06 or newer 76 2026-06-03T19:30:49.380Z [vost0:0/hevcnvenc @ 0x635196c84280] Error while opening encoder - maybe incorrect parameters such as bitrate, rate, width or height. 77 2026-06-03T19:30:49.380Z [vf0:0 @ 0x635196c84900] Error sending frames to consumers: Operation not permitted 78 2026-06-03T19:30:49.380Z 79 2026-06-03T19:30:49.380Z [vf0:0 @ 0x635196c84900] Task finished with error code: -1 (Operation not permitted) 80 2026-06-03T19:30:49.380Z [vf0:0 @ 0x635196c84900] Terminating thread with return code -1 (Operation not permitted) 81 2026-06-03T19:30:49.380Z 82 2026-06-03T19:30:49.380Z [vost0:0/hevcnvenc @ 0x635196c84280] Could not open encoder before EOF 83 2026-06-03T19:30:49.380Z [vost0:0/hevcnvenc @ 0x635196c84280] Task finished with error code: -22 (Invalid argument) 84 2026-06-03T19:30:49.380Z [vost0:0/hevcnvenc @ 0x635196c84280] Terminating thread with return code -22 (Invalid argument) 85 2026-06-03T19:30:49.380Z 86 2026-06-03T19:30:49.380Z [out0/matroska @ 0x635196c83500] Nothing was written into output file, because at least one of its streams received no packets. 87 2026-06-03T19:30:49.380Z frame= 0 fps=0.0 q=0.0 Lsize= 0KiB time=N/A bitrate=N/A speed=N/A 88 2026-06-03T19:30:49.380Z 89 2026-06-03T19:30:49.380Z Conversion failed! 90 2026-06-03T19:30:49.380Z 91 2026-06-03T19:30:49.380Z 92 2026-06-03T19:30:49.380Z 0RovkH-cws:Node[InternalNode]:Worker[joint-jay]:[-error-] 93 2026-06-03T19:30:49.380Z 0RovkH-cws:Node[InternalNode]:Worker[joint-jay]:CLI code: 255 94 2026-06-03T19:30:49.381Z 0RovkH-cws:Node[InternalNode]:Worker[joint-jay]:Last 200 lines of CLI log: 95 2026-06-03T19:30:49.381Z 0RovkH-cws:Node[InternalNode]:Worker[joint-jay]:b.Thread closed, code: 255
tomspark wrote:
That log pins it exactly: Tdarr IS trying the GPU (good — your plugin's right), but ffmpeg can't load the Nvidia encode/decode libraries ("Cannot load libnvidia-encode.so.1" / "libnvcuvid.so.1"). Those come from the "video" capability — so it's still not reaching the container. Quick check to see whether the override actually took: sudo docker exec sb-tdarr printenv NVIDIADRIVERCAPABILITIES If that prints "all", the override applied and the encode libraries are missing on the HOST side (some Nvidia driver installs ship the display driver but not the NVENC/NVDEC libs) — fixable by reinstalling the full driver + the container toolkit. If it prints nothing, the override didn't take and we just re-apply it. Tell me which you get and I'll give you the exact next step.
gdavidson26 wrote:
it printed out. "computer, video, utility"
tomspark wrote:
Good — so "video" IS enabled, which means the capability was never the real blocker. The encode library itself just isn't reaching the container, and that's a host-side driver thing on the machine your GPU lives on. Two quick checks to confirm and size up the fix: sudo docker exec sb-tdarr bash -c "nvidia-smi --query-gpu=driverversion --format=csv,noheader; ls /usr/lib/x8664-linux-gnu/libnvidia-encode.so 2&1" That prints your driver version and whether the NVENC library is present. If it says "No such file" (and/or the driver is older than 520.56.06), the fix is to reinstall the FULL Nvidia driver including the encode/decode libraries — the basic/display driver on its own doesn't ship NVENC. Paste what it shows and I'll give you the exact step for your setup.
gdavidson26 wrote:
Here is what was printed out: "gabriel@sparkbox-stack:~$ sudo docker exec sb-tdarr bash -c "nvidia-smi --query-gpu=driverversion --format=csv,noheader; ls /usr/lib/x8664-linux-gnu/libnvidia-encode.so 2&1" 595.71.05 ls: cannot access '/usr/lib/x8664-linux-gnu/libnvidia-encode.so': No such file or directory "
tomspark wrote:
That's the answer right there — your driver's plenty new (595, way above the 520 minimum), but the NVENC encode library isn't on the box at all (that "No such file" on libnvidia-encode), so ffmpeg has nothing to load. The encode/decode libs just didn't come with your driver install. Quick check — is it anywhere on the host: find /usr/lib /usr/lib64 -name 'libnvidia-encode.so' 2/dev/null If that FINDS it, just re-wire the container toolkit: sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker, then restart Tdarr. If it finds NOTHING, you'll need to reinstall the Nvidia driver so the encode libraries come with it — tell me which distro and how you installed the driver and I'll give you the exact command. This bit's your host's driver rather than SparkBox, but I'll get you over the line.
gdavidson26 wrote:
It found nothing. I am using ubuntu distro. I installed them by downloading nvidia 595-server drivers. I just installed the encoding driver's and that seemed to work. Had a hiccup where when I first started the transcoding it crashed sparkbox and restarted it but it seems like it has stabilized and I haven't had that issue again.
tomspark wrote:
There it is — that's exactly the culprit. The "-server" Nvidia drivers on Ubuntu are headless and leave OUT the NVENC encode/decode libraries, so transcoding had nothing to load; installing the encoding drivers adds them back. Nice work getting there yourself. That one-time crash when you first kicked off a transcode was most likely just the GPU spinning up under load — since it's been stable since, you're good. If it ever comes back, grab the Tdarr/sparkbox logs from around that moment and I'll dig in, but it sounds like you're all set with GPU transcoding now. Enjoy it! 🎬