UMS Blocks HDD Access through SMB

Severe SMB performance degradation while UMS is running on Windows Server 2019

Summary

I am seeing severe SMB performance degradation when Universal Media Server is running on my Windows Server 2019 NAS.

The same media directories are configured in UMS and also shared through normal Windows SMB shares. When UMS is closed, SMB works normally and I can copy files from the NAS to a client PC at around 270 MB/s.

When UMS is running, newly started SMB copy operations or video playback over SMB become almost unusable. Copy speed can drop to around 355 KB/s. If I close UMS while such a slow copy is running, the speed immediately jumps back to around 270 MB/s.

Task Manager and Resource Monitor on the server show no obvious CPU, RAM, disk, or network saturation during the issue.

System

• OS: Windows Server 2019
• Hardware: Ryzen 9 7940HS NAS
• Storage: 20 TB HDD containing the media library
• SMB: Windows file sharing
• UMS: running on the same server
• Client playback: VLC over SMB from a Windows client
• VLC cache on client: 10 seconds
• Media directories: same directories are used by UMS and shared through SMB

Copy behavior

1. With UMS closed, copying from the SMB share reaches around 270 MB/s.
2. If a copy is already running and UMS is started during that copy, the speed remains stable until the copy finishes.
3. After UMS is running, starting a new SMB copy operation from the same share can drop to around 355 KB/s.
4. Closing UMS while the slow copy is running immediately restores normal copy speed.

This suggests that UMS is not simply saturating disk or network bandwidth. Instead, it seems to affect newly opened SMB file access while UMS is active.

VLC playback behavior

When I play a video with VLC on a client PC over SMB while UMS is not running, playback is smooth.

If I start UMS while the video is already playing, playback starts hanging and becomes almost unwatchable.

If UMS is already running and I start playback over SMB, the first seconds play smoothly, because my VLC has a 10 second cache configured. After that cache is exhausted, playback starts hanging again.

Expected behavior

UMS should not interfere with normal Windows SMB file access. Files from the same directories should still be readable over SMB at normal speed, especially when there is no active transcoding and no obvious system load.

Additional notes

• The same files and shares work normally when UMS is not running.
• The server appears mostly idle during the issue.
• No specific media title is required to reproduce the behavior.

Troubleshooting performed

• Restarted the server; the issue came back when UMS was running again.
• Checked Task Manager and Resource Monitor on the server via Remote Desktop.
• Confirmed that CPU, RAM, disk, and network usage do not show any obvious saturation during the issue.
• Increased/used a 10 second VLC cache on the client; this only hides the issue for the first few seconds and does not solve it.
• Verified that the problem is not tied to a specific media title.
• Used RAMMap on the server to check whether the accessed media file was being cached by Windows. The file did appear in the Windows file cache, but only around 240 MB were cached. This did not explain the issue.
• Checked Resource Monitor during VLC stalls and slow SMB copies. Disk activity stayed close to zero during the stall, so the HDD itself did not appear to be saturated.
• Checked open SMB files with Get-SmbOpenFile. The affected folders/files were visible as open SMB handles, but Locks was 0, so there were no obvious SMB byte-range locks.
• Temporarily disabled SMB leasing with:
  Set-SmbServerConfiguration -EnableLeasing $false -Force
  Then the SMB/client connection was reset and the test was repeated. This did not resolve the issue.
• Used Sysinternals Handle to check local file handles on the server. UMS was confirmed to be running as javaw.exe with ums.jar.
• Handle showed javaw.exe holding handles to affected movie folders, but no matching handle was found for the actual .mkv file itself.
• Verified that the issue still occurs even when UMS appears idle and is not actively transcoding or visibly scanning anything.

Reproduce the issue on Windows Server 2019 by comparing new SMB copies with UMS stopped and running, using the described VLC and PowerShell tests. Start by examining UMS's access to the shared media folders and the javaw.exe/ums.jar handles. Done means UMS no longer causes newly opened SMB copies or playback to stall.