We’ve been doing some more tests, and we had the same issue with any HTTP server running from that Windows Server 2019 and other HTTP clients running on an Apple platform, even if they’re not related to video. For example it also happens with VLC on macOS playing a video from a simple HTTP server running from Windows Server 2019.
More specifically we tested serving a movie file with an nginx server, and download it from macOS using just curl, since that removes all the “video playback” stuff and simplifies our investigation, and we had this very same problem. So it doesn’t seem to be a bug in any of the Plex code, but either on the Windows network stack or Apple’s network/HTTP implementation.
Our expert @Ridley digged into the exact packet exchange between client and server and noticed Apple code was doing something unusual but allowed: “the client -macOS- appears to be deliberately delaying ACKs for full-sized segments beyond the 2 specified in RFC 1122, but that’s marked as a SHOULD, not a MUST, so it’s not out of spec”.
So for now we think this is a bug in Windows Server 2019, we haven’t found any workarounds for it yet, so right now we can only suggest to avoid using Windows Server 2019 if you have any Apple-based client.
Thank you for having @Ridley look into the issue. It’s unfortunate the issue appears to be centered around Windows Server 2019. For me, going back to an older OS like Windows Server 2016 is not an option, as I’ve put a lot of work into my server build. However, I may consider running Plex within a Windows 10 VM via Hyper-V on that same server, considering the Standard license lets you run 2 Hyper-V VMs within. But for now I will leave EVP disabled on all the Apple TVs in my home and wait things out for a bit in case a workaround or fix is discovered.
@fcapizzo does it work if you keep the EVP enabled and disable Direct Play only?
If my theory is correct, the old player works because it forces transcoding, which means splitting the video in multiple small files, which doesn’t present this problem. Disabling Direct Play should do the same with EVP (but without the need for transcoding in most scenarios).
I set the 2 options on the one of my Plex ATV clients and tried my same test video as always. Playback paused less than 30 seconds in. I think it may have been transcoding, but even if it was my server can handle that. I’ll try a variety of other videos when I get a chance.
I face pretty much the same problem except PMS running inside docker remotely. My remote server is able to handle plex with no problems. in fact the majority of time i can stream 4K with 0 problems. that until recent updates for AppleTV.
Sometimes at random hour, plex would start buffering every sec. on ios/ATV, for no reason no network change nothing. before that i watched similarity sized episodes/movies with 0 problem.
My home network setup is Router > switch > ATV/windows. all files are directly played with 0 transcode or subtitle. When i experienced the buffering i switched to plex for windows, and to my suprise 0 buffering.
so this lead me to believe it’s network related problem in ATV. so i decided to test the network of both server and ATV, server is reporting 1Gbps up/down as expected. my ATV reporting 600-800Mbps, which is more than enough to stream 1080p.
So i went ahead and put small nginx docker container that serve my media. then tried to play them via VLC in ATV. 0 buffering.
I suspect that there is a problem when file is served via “/library/parts/183311/1440876044/file.mkv” to mpv, i tried both direct link and plex link. the direct link i was able to buffer almost all the movie quickly. on plex side barely able to handle few secs before buffering again.
Using same links in plex for windows i have 0 problem while the same link buffers in ATV. after an hour or plex start running with 0 buffering.
I have no idea how to fix something that i can’t trace or able to produce it whenever i want to test things out. i still believe it’s MPV problem.
I think this is something on the TVOS side - App or device, I’m unsure.
I run Plex server on an Ubuntu VM on ESX. It’s been fine for years, but now stutters, and has done for the past couple of months.
For now, we just enable transcoding after starting the movie / show, which fixes it instantly. I thought this would have sorted its self out by now, as all components get regular updates.
I’d hazard a guess this is an a specific issue with Apple TV, Plex App and direct play or stream, at least for now.
I posted the following on a Constant Buffering when using Plex on home network thread, since my experience/issues were similar. I’m posting it here since I too think there is also an issue with macOS-, tvOS-, and possibly iPadOS-based apps (maybe an Apple issue?).
I’m having (or had) the same issues with
macOS (10.15.3) app on MacBook Pro (2016)
tvOS (13.4) app on AppleTV 4K
iPadOS (13.4) on iPad Pro (2020)
macOS (10.15.4) app on MacBook Pro (2016)
Not having (or did not have) the issue with
iOS (13.3.1) app on iPhone XS
iOS (13.4.1) app on iPhone XS
iOS (13.3) app on iPad mini 4
iPadOS (13.4.1) app on iPad mini 4
iPadOS (13.4.1) app on iPad Pro (2020)
Server is Plex Media Server v1.19.3.2764-ef515a800 on Synology DS918+ x86_64 DSM 6.2.2.24922-4, Processor Intel® Celeron® CPU J3455 @ 1.50GHz
I checked my logs against @DaddyMD’s and there were (many) similar errors:
DEBUG - Auth: authenticated user 1 as ****@****.com
DEBUG - Request: [192.168.1.84:53341 (Subnet)] GET /library/parts/9177/1589683316/file.mp4 (7 live) TLS Signed-in Token (****@****.com) (range: bytes=5546602-)
DEBUG - Content-Length of /volume1/Media/Movies/****.mp4 is 5022951951 (of total: 5028498553).
DEBUG - Failed to stream media, client probably disconnected after 360448 bytes: 104 - Connection reset by peer
DEBUG - Completed after connection close: [192.168.1.84:53340] 206 GET /library/parts/9177/1589683316/file.mp4 (7 live) TLS 188ms 360448 bytes (range: bytes=102985-)
I should probably add that the issue only exists for certain movies. I am not 100% certain, but I am pretty confident it’s only been for movies added to Plex after a certain date, which is why I was thinking it was a Plex issue with the client apps mentioned above.
I wonder if the TVOS has been accidentally capped at 3mb/s
If you enable the “Automatic Quality Adjust (Beta)” on the TVOS app, the function kicks in because it believes there isn’t enough bandwidth on the LAN.
In my testing 3.5 mb/s was too much.
Perhaps some test code (bandwidth simulation) for the beta feature has been left behind.
I only have the issue on TVOS, and it does affect my older library items that have always worked previously.
All other clients are unaffected.
Can anybody confirm when the beta feature was added, and if these issues arrived at the same time?
I’m in the same boat as you, configuring a 2016 server or even a 2012R2 server which I used previously is looking like the best option. This really sucks.
I don’t know, maybe an alternative player at this point may be the best option. Trying not to re-invent the wheel but not sure how much longer I want to wait while Plex sorts this out…
I am also in the exact same boat.
I have 2 networks each with their own Plex server each on 2019 vms.
Each network has multiple ATV4Ks experiencing the issue. The issue does not however occur on ATV4.
I noticed that the issue only seemed to occur when direct play was occurring and that disabling EVP provided some relief.
Very curious as to what resolves this issue for now changing to a 2016 VM might be the best action.
If it’s not, then it’s probably a different issue so I’d suggest to open a new thread posting the specific details of your setup and logs so we don’t lose them, and we’ll look into those other problems as soon as we have a chance.
@sergiou87 I just wanted to check up on this issue to see any further testing or workarounds are still being done to resolve this issue. Even if the issue is related to Windows Server 2019 itself, I still hope the developers will be able to fix this so EVP can be left on, since that’s the default option now.
Have anyone tested if the issue exists on Windows Server ACore v2004 / 20h1 / 19041? Aka the Windows Server equivalent of the new Windows 10 v2004 / 20h1 / 19041 that just got released?
You have to be on the semi-annual release branch to get this version, a branch that does not come with GUI / Desktop Experience.
I’m considering giving it a go. I have no need for GUI on my server anyways. I don’t want to go back to Windows Server 2016…
All my tests running Plex from various operating systems within Hyper-V has given the same results as Windows Server 2019 so I’m not entirely convinced that Server 2019 is to blame but then again those tests are done from within Hyper-V on the Windows Server so it might still be the one causing the issues and making it so it doesn’t work for virtual machines either.
I tried Windows 10 v2004, Windows 10 v1809, Ubuntu Server 20.04 LTS and they all gave the same results and issues.
I also want to comment that I am very concerned that the option to even use the old player will just disappear some day, before this issue is resolved. If I’m forced to use the new player and I’m still having this buffering issue, Plex will be unusable for me.
I share these concerns - moving away from Win2019 would be a big hassle as all data, config, Tautulli, etc. is on that server. I understand that the issue is not directly related to Plex, but maybe the EVP can be tweaked to recognize Win2019 on the PMS side and alter the behaviour in direction of the old player with regard to the transfer of data.
Also, raising this issue with Microsoft would be important as it appears to be having impact in a lot of situations, so there should be some inclination to get it fixed.
Aside from this it is crucial to keep the old player alive…
I would just like to confirm that Windows Server ACore v2004 / 20h1 / 19041 seems to be working without any issues so far. I also applied yesterdays cumulative update and it’s still going strong.
There are no plans at all to remove the old player. It’s used for WebShows, News and the Movies&TV source, and is the only way of making PiP and AirPlay work.
The Enhanced Video Player is only used for “regular playback” (meaning, no PiP and no AirPlay) of personal media content from users’ servers, and I don’t see that changing anytime soon…
Regarding the bug itself: we’re not looking into workarounds right now, and I can’t commit to anything in the short term
I have this same issue. Server 2019 with two ReFS volumes hosting my media. H/W transcoding powered by a GTX1660 Super.
If I created an Ubuntu LTS 20.04 VM and connected it via HyperV - with the host OS (Server 2019) unable to share this second NIC, would I still have the problem?
Looking for a way to keep my media in-place on ReFS volumes so I don’t have to copy them out to something and then copy them back when/if I move to Ubuntu.
I could try Win10 Enterprise - does anyone have any way to test this with Win10 Enterprise easily?
I tried it with disabling Direct Play, so that it would Direct Stream using the new EVP on my AppleTV 4k - same issue. Watching the on-screen details shows the buffer slowly drop to 0 seconds and then playback freezes and I get a response “Your server is not powerful enough to play this item”.
