DaVinci Resolve Render Failures Fixed by Disabling SMB Multichannel

DaVinci Resolve Render Failures Fixed by Disabling SMB Multichannel (TrueNAS SCALE)

I’m posting this as a data point for other TrueNAS SCALE users running high‑bandwidth media workloads (especially DaVinci Resolve) over SMB.

TL;DR

If you are using DaVinci Resolve on Windows with TrueNAS SCALE (Samba) over a fast link (10/25 GbE) and are seeing repeatable render failures (especially at “randomly repeatable” time points in the timeline) try disabling SMB Multichannel. In my case, this immediately resolved deterministic render failures and improved sustained SMB throughput.


Environment

  • NAS: TrueNAS SCALE (Linux + Samba)

  • Client: Windows workstation

  • Network: 25 GbE (single client)

  • Protocol: SMB

  • Application: DaVinci Resolve

  • Source media: DNxHR HQ

  • Render output: DNxHR HQX 4K 10‑bit @ 23.976 fps

  • Audio: 16‑channel PCM

  • Workload: Very large sequential media files (hundreds of GB)


Symptoms

  • DaVinci Resolve renders failed reliably at the same timeline timecode.

  • Failures occurred suddenly (no FPS drop or visible I/O slowdown beforehand).

  • Re‑running the render would fail at the same point.

  • File copies via Explorer worked fine, which initially made this look like a Resolve or media issue rather than storage.


What Was Tested / Ruled Out

  • Media corruption (DNxHR HQ source verified)

  • Storage hardware issues

  • ZFS pool layout and performance

  • RAM stability

  • Network bandwidth limitations

None of the above resolved the issue.


Key Change

Disabled SMB Multichannel on the TrueNAS SCALE system.

After doing this:

  • Sustained SMB copy speeds increased from ~1.3 GB/s to ~1.7 GB/s.

  • DaVinci Resolve completed a full render successfully.

  • A second full render also completed successfully.

  • Renders now finish cleanly with no hang or error at the end.

No other changes were made.


Why This Matters

This appears to be an edge‑case interaction between:

  • DaVinci Resolve’s I/O behavior (mixed large sequential reads/writes + small metadata operations), and

  • Samba SMB Multichannel on Linux under a single‑client, extremely high‑throughput workload.

SMB Multichannel is working as designed, but the additional coordination, thread scheduling, and tail‑latency variability seem to be enough to trip Resolve at deterministic points in the timeline.

Disabling Multichannel forces a single, ordered TCP stream, which in this case resulted in:

  • lower overhead,

  • more deterministic I/O,

  • and higher real‑world throughput for this workload.


Recommendation

For Resolve‑critical workloads on TrueNAS SCALE:

  • Leave SMB Multichannel OFF.

  • Prefer deterministic single‑stream SMB behavior over maximum theoretical parallelism.

If SMB Multichannel is needed for other use cases, consider isolating those workloads to a different system or share.


Closing

Posting this in case it saves someone else a lot of time. This configuration produced repeatable failures that disappeared immediately once SMB Multichannel was disabled.

Happy to provide additional details or testing if it helps the community.

1 Like