Random Pauses During Playback

[dwyatt 2]

Hi, longtime Emby user here (since the MediaBrowser days running it in Windows Media Center - circa 2010 I believe!)

I have a playback issue that I'm struggling to solve/understand. The symptom is that seemingly randomly (usually it will happen a few times in quick succession, but then go hours/days before it happens again) I have several clients who report that playback pauses for 5-30 seconds, then resumes on it's own with no interaction from them. The main user affected is off-site and accessing from the AppleTV client so I had assumed this was a network issue on their side or something about the AppleTV app (not an Apple user myself). But then a couple months ago this same problem started happening to me locally from my Shield (using Emby Android, not the Android TV version) and it's been driving me (and my family) crazy. Finally I have some time to try to figure it out. 

A bit about my environment. Up until last week, I was running emby server on a Lenovo MicroPC which had worked fine for years but I thought maybe this was the issue. I have now moved it to my new server and the problem remains exactly as before so I guess that wasn't the problem. New machine details are below.

• Emby server is running on docker in a Debian VM on a proxmox host
• Proxmox host is a pretty powerful machine: AMD Epyc with 32 cores, 128GB ram, Quadro 1000 GPU passed through to docker VM for hardware acceleration (tested thoroughly and this works great)
• Transcoding is not the issue - files are being direct played (no transcode logs being generated to share)
• I do have a proxy (Traefik) that was in use for the below logs. But I've tried bypassing this locally before and the problem persisted. I have just now bypassed it again (logging in using local IP instead of through proxy address) and will report back with more logs once the problem happens again.
• Actual media files are on this same proxmox host but a different VM (TrueNAS with the HBA passed through to it - ZFS underlying filesystem with no drive errors or anything reported). The docker VM has a CIFS mount to the TrueNAS share and this is passed to Emby docker container using a volume. This is how I've had it setup for years without issues (prior to the relatively recent issue). I don't think it's relevant, but TrueNAS is fairly new as well - 2 months ago files were on a Synology NAS and the problem existed then so I don't think it's the media share that's the issue. It's now on completely different drives, with a different filesystem, on a different host. Completely different setup other than the CIFS share to access it and the problem is the same. 
• Networking wise, I'm running Ubiquity gear. The connection between the docker VM and TrueNAS is virtual so it's incredibly fast (about 25Gbps in my testing). The connection from my proxmox host to my networking gear is 10GbE. The connection from network gear to Shield client is 1GbE. From another computer connected with 10GbE, I can read from my media share on TrueNAS at upwards of 800MB/s (~5-6Gbps).

Logs from both server and android app are attached (I manually redacted my server address in the Android app - why doesn't the share button in the Android app work?). Have a look around the 22:27 mark. Here's what I see in the server log (note the "Response completed after client disconnected" line and then the "Playback progress (Unpause)" line. This is reported every time this happens and seems to be the only real error I can see in the logs related to this event making me think it's likely not a Emby server issue.

2026-02-28 22:27:03.241 Info VideoService-0HNJJB2U35J29:00000003: http/1.1 Response completed after client disconnected to host2. Time: 920922ms. GET http://emby_remote_ip/emby/videos/160697/original.mkv?DeviceId=99ee178fac43b052&MediaSourceId=mediasource_160697&PlaySessionId=336f46eff10f462cad79255c24ac365e&api_key=x_secret10_x. Headers: Content-Type=video/x-matroska, Date=Sun, 01 Mar 2026 05:11:42 GMT, Server=UPnP/1.0 DLNADOC/1.50, Accept-Ranges=bytes, Cache-Control=private, no-transform, Content-Range=bytes 9771-9963158044/9963158045, ETag="af4621eec7ab31973ddf144c3e7394df", Content-Length=9963148274, Cross-Origin-Resource-Policy=cross-origin, Private-Network-Access-Name=Media Server, Private-Network-Access-Id=31c02b8fef8147a1b2701b40eb6c826f
2026-02-28 22:27:03.414 Debug PlaystateService-0HNJJB2U35J3I:00000002: InitRemoteConnectionInfo - ipAddressFromHeaders: host9
2026-02-28 22:27:03.414 Debug PlaystateService-0HNJJB2U35J3I:00000002: InitRemoteConnectionInfo - rejecting ipAddressFromHeaders as on local network
2026-02-28 22:27:03.414 Info PlaystateService-0HNJJB2U35J3I:00000002: http/1.1 POST http://emby_remote_ip/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Android&X-Emby-Device-Name=SHIELD&X-Emby-Device-Id=99ee178fac43b052&X-Emby-Client-Version=3.5.28&X-Emby-Token=x_secret10_x&X-Emby-Language=en-us&reqformat=json. Source Ip: host2, UserAgent: Mozilla/5.0 (Linux; Android 11; SHIELD Android TV Build/RQ1A.210105.003; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/145.0.7632.79 Mobile Safari/537.36
2026-02-28 22:27:03.415 Info SessionManager: Playback progress (Unpause) reported by app Emby for Android 3.5.28 on SHIELD playing Hijack - S1, Ep7 - Brace Brace Brace. Position: 946171 ms. PlaySessionId: 336f46eff10f462cad79255c24ac365e. IsPaused: False

In the Android app log, I see the below. Note the STATE_BUFFERING and the internalError. 

Sat Feb 28 22:26:05.633 GMT-07:00 2026 EventLogger: loading [eventTime=866.69, mediaPos=902.21, window=0, period=0, true]
Sat Feb 28 22:26:05.637 GMT-07:00 2026 EventLogger: loading [eventTime=866.70, mediaPos=902.21, window=0, period=0, false]
Sat Feb 28 22:26:06.050 GMT-07:00 2026 EventLogger: loading [eventTime=867.11, mediaPos=902.62, window=0, period=0, true]
Sat Feb 28 22:26:49.582 GMT-07:00 2026 EventLogger: rendererReady [eventTime=910.64, mediaPos=946.15, window=0, period=0, rendererIndex=0, video, false]
Sat Feb 28 22:26:49.606 GMT-07:00 2026 EventLogger: droppedFrames [eventTime=910.67, mediaPos=946.15, window=0, period=0, 1]
Sat Feb 28 22:26:49.607 GMT-07:00 2026 EventLogger: state [eventTime=910.67, mediaPos=946.15, window=0, period=0, BUFFERING]
Sat Feb 28 22:26:49.607 GMT-07:00 2026 PlaybackManager state: STATE_BUFFERING
Sat Feb 28 22:26:49.612 GMT-07:00 2026 EventLogger: isPlaying [eventTime=910.67, mediaPos=946.17, window=0, period=0, false]
Sat Feb 28 22:26:59.921 GMT-07:00 2026 ExoPlayer onLoadError, wasCanceled false
Sat Feb 28 22:26:59.924 GMT-07:00 2026 EventLogger: internalError [eventTime=920.98, mediaPos=946.17, window=0, period=0, loadError
  androidx.media3.datasource.HttpDataSource$HttpDataSourceException: java.net.SocketTimeoutException: timeout
      at androidx.media3.datasource.okhttp.OkHttpDataSource.read(OkHttpDataSource.java:352)
      at androidx.media3.datasource.DefaultDataSource.read(DefaultDataSource.java:281)
      at androidx.media3.datasource.StatsDataSource.read(StatsDataSource.java:103)
      at androidx.media3.extractor.DefaultExtractorInput.readFromUpstream(DefaultExtractorInput.java:298)
      at androidx.media3.extractor.DefaultExtractorInput.read(DefaultExtractorInput.java:70)
      at androidx.media3.exoplayer.source.SampleDataQueue.sampleData(SampleDataQueue.java:178)
      at androidx.media3.exoplayer.source.SampleQueue.sampleData(SampleQueue.java:602)
      at androidx.media3.extractor.TrackOutput$-CC.$default$sampleData(TrackOutput.java:168)
      at androidx.media3.exoplayer.source.SampleQueue.sampleData(Unknown Source:0)
      at androidx.media3.extractor.mkv.MatroskaExtractor.writeToOutput(MatroskaExtractor.java:2030)
      at androidx.media3.extractor.mkv.MatroskaExtractor.writeSampleData(MatroskaExtractor.java:1841)
      at androidx.media3.extractor.mkv.MatroskaExtractor.binaryElement(MatroskaExtractor.java:1517)
      at androidx.media3.extractor.mkv.MatroskaExtractor$InnerEbmlProcessor.binaryElement(MatroskaExtractor.java:2281)
      at androidx.media3.extractor.mkv.DefaultEbmlReader.read(DefaultEbmlReader.java:145)
      at androidx.media3.extractor.mkv.MatroskaExtractor.read(MatroskaExtractor.java:650)
      at androidx.media3.exoplayer.source.BundledExtractorsAdapter.read(BundledExtractorsAdapter.java:149)
      at androidx.media3.exoplayer.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:1146)
      at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:453)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
      at java.lang.Thread.run(Thread.java:923)
  Caused by: java.net.SocketTimeoutException: timeout
      at okhttp3.internal.http2.Http2Stream$StreamTimeout.newTimeoutException(Http2Stream.kt:675)
      at okhttp3.internal.http2.Http2Stream$StreamTimeout.exitAndThrowIfTimedOut(Http2Stream.kt:684)
      at okhttp3.internal.http2.Http2Stream$FramingSource.read(Http2Stream.kt:380)
      at okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.kt:281)
      at okio.RealBufferedSource$inputStream$1.read(RealBufferedSource.kt:161)
      at androidx.media3.datasource.okhttp.OkHttpDataSource.readInternal(OkHttpDataSource.java:520)
      at androidx.media3.datasource.okhttp.OkHttpDataSource.read(OkHttpDataSource.java:350)
      ... 20 more
]
Sat Feb 28 22:26:59.925 GMT-07:00 2026 onLoadStarted windowIndex: 0 retryCount: 1
Sat Feb 28 22:26:59.948 GMT-07:00 2026 EventLogger: rendererReady [eventTime=921.01, mediaPos=946.17, window=0, period=0, rendererIndex=0, video, true]
Sat Feb 28 22:27:02.783 GMT-07:00 2026 EventLogger: state [eventTime=923.84, mediaPos=946.17, window=0, period=0, READY]
Sat Feb 28 22:27:02.783 GMT-07:00 2026 PlaybackManager state: STATE_PLAYING
Sat Feb 28 22:27:02.784 GMT-07:00 2026 EventLogger: isPlaying [eventTime=923.84, mediaPos=946.17, window=0, period=0, true]
Sat Feb 28 22:27:02.788 GMT-07:00 2026 IsPlaying true

The Android app log makes me wonder if this is a networking issue, but I'd like confirmation of that before I spend too much time going down that route. 

Let me know if there's any testing you would recommend to help me try to figure this out. 

embyserver-63907920000.txt emby_android_1772334813184_redacted.txt

[ebr 16357]

4 hours ago, dwyatt said:

The Android app log makes me wonder if this is a networking issue

Hi.  It would appear so:

4 hours ago, dwyatt said:

Caused by: java.net.SocketTimeoutException: timeout

 

[Luke 42302]

Yes I would try lowering the in app quality setting and see if that helps.

[Interwebz 0]

Hi, just want to chime in that I have the same issue under similar conditions. I used to have an Emby Synology container having the same issues. Now I'm running a Proxmox LXC and quite often I get these unexpected pauses that often resume by themselves if you wait long enoguh but sometimes not. Totally random and not possible to recreate. It's getting a bit annoying which led me here. I'm using an Apple TV.

[visproduction 338]

Of interest - Recent post regarding video stuttering with Apple TV - Apparently, this is a known issue for many years with Apple TV.  Often updates happen behind the scenes and users are unaware that anything changed.

https://thetechgorilla.com/apple-tv-stuttering/

Edited 13 minutes ago by visproduction

[dwyatt 2]

I owe you all an update: my problem had nothing to do with Emby or my network.

You can read all about my adventure over here: https://forums.servethehome.com/index.php?threads/lsi-9400-16i-power-on-or-device-reset-occurred.55002/ but in summary, the backplane in my server chassis (Gooxi RMC4136-670-HSE chassis) had an old firmware that had issues with some health checking commands while drives were loaded (reading or writing). If I was streaming something from it and a TrueNAS health check occurred (which turns out is every 90 minutes in 25.10) then it would cause the drives to start timing out leading to ZFS halting the pool while it recovers the drives and while that is happening all further reading is blocked which from Emby's perspective looked like a network timeout. It would take about 5 minutes for all the drives to recover and then it would be fine until the next health check. Gooxi was able to provide a newer firmware and it has completely resolved the issue.