Media pauses during playback

[Depechie 13]

I'm a bit stuck with a problem...
Since a few weeks any movie or series episode that I play; will randomly auto pause and after a few seconds ( but it is long if not a minute ) it will start again.

I have taken a look in the logs and it is not looking good.
It is full of these errors - almost every minute ( looking at the timestamps ) - although the pauses are only a few times for 1 episode of a serie.

2026-01-19 20:55:44.254 Error VideoService-0HNIGJL46R1AK:00000001: Error processing request
	*** Error Report ***
	Version: 4.9.3.0
	Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
	Operating system: Linux version 6.17.4-2-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 6.17.4-2
	OS/Process: x64/x64
	Framework: .NET 8.0.22
	Runtime: opt/emby-server/system/System.Private.CoreLib.dll
	Processor count: 4
	Data path: /var/lib/emby
	Application path: /opt/emby-server/system
	System.IO.IOException: System.IO.IOException: Input/output error : '/mnt/series/***/***.mkv'
	   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.ExecuteInternal()
	--- End of stack trace from previous location ---
	   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.GetResult(Int16 token)
	   at Emby.Server.Implementations.IO.StreamHelper.CopyToAsync(Stream source, PipeWriter destination, Int32 bufferSize, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.FileWriter.WriteToAsync(IResponse response, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, RestPath restPath, String urlString, String localPath, String contentTypeInPath, CancellationToken cancellationToken)
	Source: System.Private.CoreLib
	TargetSite: Void ExecuteInternal()

So obviously something is going on.
But I have tried several tweaks and have not yet found a solution.

So are there tips on how to handle this?
The issue, of course, is that before this I did do some hardware changes... but it are several ones and not sure if they would matter or not.

Because the most obvious 2 things I can think of is either:
1. Disk failure
2. Network issues

But what do I know

Some feedback on my current setup.
- Unifi network
- Synology NAS that hosts the media files in RAID 5 configuration
- Intel NUC running Proxmox and hosting Emby in an LXC container - Emby version 4.9.3.0

Some facts about the hardware changes before the issues, I needed to redo the NUC because of an eMMC drive failure. I also redid the Unifi network ( bought a Cloud gateway fiber ), funny though the NAS did not change.

Help most certainly welcome, because media viewing is no longer a joy

Edited January 21 by Depechie
Wording

[Luke 42866]

Hi, this suggests a problem with the file mount or underlying storage. What type of mount is it?

[Depechie 13]

Hey Luke,

So the LXC is a linux container and running in Proxmox.
The proxmox pve has in it /etc/fstab entries to the synology shared folders with the `nfs defaults 0 0` setting ( so NFS shares ).

Those pve mount points are passed to the lxc.

 

[Luke 42866]

The System.IO.IOException: Input/output error is a general exception indicating a failure during an input or output operation, such as reading from or writing to a file or a network stream. This error is often caused by underlying system or hardware issues rather than a simple programming error. 

[Luke 42866]

• Insufficient Disk Space: The disk where the operation is taking place is full or near capacity.
  • Fix: Check disk usage and free up space if necessary.
• Network or Mounting Issues (especially in Docker/Linux environments): The error often occurs when dealing with network shares (like NFS or CIFS) mounted within a container or a system, due to permission mapping issues or network disruptions. The error message "Input/output error" in these cases can be a generic wrapper for underlying system errors like "Invalid argument".
  • Fix: Investigate the specific mapping and permission settings for network mounts. Manually testing file operations (like copy or move) as the application's user can help diagnose if the issue is with the mount itself.
• Hardware or System Disk Errors: The exception can be a sign of a physical problem with the storage device, such as a failing hard drive or an I/O device error.
  • Fix: Run diagnostic tools (like SMART tests) on the disk to check for hardware health.
• Unexpected Disruptions: The operation was interrupted unexpectedly, such as a network connection loss during data transfer. 

[Depechie 13]

I have been suspecting the disk space element.

Because first time I got this was when I got the 80% marker of the raid 5 volume.

But although I tried removing stuff from the nas because of the raid I have no idea where it is being removed or where the limit is happening.

Also not great that I cannot use more than 80% capacity

[Luke 42866]

OK please keep us posted if you find anything, thanks.

[TMCsw 286]

4 hours ago, Depechie said:

Because first time I got this was when I got the 80% marker of the raid 5 volume.

I doubt that an 80% full drive is causing this!

I'm not a Syomlogy user, but I would start here:

1. Check the status of the RAID 5 
2. Check the S.M.A.R.T status of the individual drives 

It could be a metwork problem too??

[Depechie 13]

Yeah did that already…

In synology you can also do a thorough smart scan and that also just said everything is fine

[Luke 42866]

Hi, are you still having an issue with this?

[Depechie 13]

Yes… but not always.

It is so very random and clearing data on the NAS is not very easy ( of if I want to be sure that is the actual issue at hand )

Pretty sure it is not a real Emby issue, so you guys can ignore this.

[visproduction 367]

Related?
https://forums.docker.com/t/docker-container-loses-network-connectivity-intermittently/120560

Quote

Fixed! I went to Release notes | Docker Docs and downloaded the latest DMG file and copied it over and overwrote the current docker (after ensuring docker is stopped. It takes a few mins to fully stop thought not visible to human eye). All good with the latest one 4.41.2. Thanks!

Also see: https://duckduckgo.com/?q=Network+or+Mounting+Issues+(especially+in+Docker%2FLinux+environments)++losing+network+connection&ia=web

[Depechie 13]

So thank god for AI I guess
Got deepseek taking a look at my setup and it got to this in the end...

UPDATE: found the root cause of the "random pauses" + System.IO.IOException: Input/output error

Long story short: it was the NFS mount version, not disk/space/network. After weeks of chasing it,
I can now reproduce it on demand and have a fix that is verified.

ROOT CAUSE
- Emby runs in a Proxmox LXC; the movie files come from a Synology NAS over NFS (mount points
  defined in /etc/fstab on the Proxmox host and bind-mounted into the LXC).
- The mounts used NFSv4.1 with default locking (local_lock=none). .NET/Emby takes a flock
  (share-lock) on the media file when it opens it for streaming. On NFSv4.1 that flock is
  forwarded to the server as an NFSv4 byte-range lock.
- The Synology server periodically drops that lock state (lease/stateid expiration). The kernel
  client then logs: "NFS: <nas ip>: lost 1 locks", and every subsequent read through the locked
  file fails with EIO -- which Emby surfaces as System.IO.IOException: Input/output error and a
  playback pause until the file is re-opened.

PROOF (reproduced while the NAS was fully online, cold cache, so no NAS power schedule involved)
- Every Emby "Input/output error" event matched 1:1 with a kernel "lost 1 locks" event (same
  second, 97/97 on the worst evening).
- Deterministic repro on the host: open the movie file, take flock(), read continuously.
  * NFSv4.1 + flock        -> EIO partway through the file + "lost 1 locks"
  * NFSv4.1 without flock   -> full file reads fine
  * NFSv4.1 + nolock        -> still fails (kernel silently maps nolock to local_lock=none)
  * NFSv4.1 + local_lock=all -> still fails (NFSv4 client ignores this option -> /proc/mounts
    still shows local_lock=none)
  * NFSv4.0 + flock         -> full 5.8 GB file reads fine, no "lost 1 locks"

So neither nolock nor local_lock help on NFSv4.1 -- the only reliable fix I found was dropping
the NFS protocol version from 4.1 to 4.0 for these mounts.

FIX APPLIED
In /etc/fstab change "/path nfs defaults 0 0" to "/path nfs defaults,vers=4.0 0 0",
unmount and remount, then verify: /proc/mounts should show vers=4.0.
 

[Luke 42866]

Thanks for following up.