Server Version#: 1.20.5.3600
Player Version#: Plex Web 4.47.1
This has been an issue for a while but it’s finally annoying me enough that I feel the need to reach out about it.
When I’m trying to play back media on Plex on my desktop PC (Chrome) via Plex Web, my playback is limited to 4mbps 720p.
On my server, I have 4mbps 720p set as the maximum quality for external streams, but not internal.
My Plex server is on a different VLAN to my desktop, at 10.0.101.60, and my desktop at 10.0.103.80. Under the ‘LAN Networks’ field on the ‘Network’ tab in server settings, I have the following value: 10.0.0.0/255.0.0.0
Interestingly, Tautulli detects that my connection is ‘LAN’ and shows the 10.0.103.80 address as the player’s address, so I’m not accidentally going out to the internet and back in to get to my local server or anything. tcpdump on the Plex server also confirms this.
When I select the video quality options in the web player, the highest available quality option I get is 4mbps 720p. If I raise the “Limit remote stream bitrate” setting under the “Remote Access” tab to “Original”, my LAN streaming works fine and I can get Direct Play / high quality streams.
Check your logs for any mention of allowedNetworks.
Plex is hypersensitive to the formatting of that field. 10.0.0.0/8 works for me, but if there’s even an extra space in the field, it will fail to parse.
I don’t think Tautulli’s opinion is helpful here. I think it’s using a naive heuristic, maybe geo estimates, based on the IP address. I’m almost certain it isn’t aware of Plex’s allowedNetworks-based decision-making.
Interesting. 10.0.0.0/8 is now working as it should do. Though based on my previous topic (link in 2nd reply), that’s what I had originally and I changed to 10.0.0.0/255.0.0.0 in order to try and fix this as per advice from a Plex employee.
Baffling. I guess I’ll run with it for a few weeks and see if the issue comes back.
10.0.0.0/255.0.0.0 works for me too though. I’ve never noticed a difference with CIDR vs. dotted notation.
How are you routing traffic between subnets in your LAN? I don’t think that’s the problem, and your log clearly showed that Plex saw your client’s IP address and that Plex was making the “WAN” decision. I’m just curious.
Nothing out of the ordinary. Client and server are on two different /24 subnets and there’s a layer 3 router with a gateway in each that provides routing between them. Incredibly standard stuff.
Everything here points to some weird bug in the logic that determines if a client’s IP is “LAN” or “WAN”. As per my logs from last year:
Dec 15, 2019 14:48:03.220 [0x7f6f2cff9700] DEBUG - Request: [10.0.103.80:13590 (WAN)] GET /video/:/transcode/universal/....
What’s confusing is how this setting seems to ‘undo’ itself over time. Perhaps PMS updates knock the setting out and then re-applying it with a different value causes Plex to re-recognize that the ‘LAN Networks’ setting is set and starts honoring it again?
What’s even more confusing, though, is how this only seems to affect Plex Web. I have other clients on 10.0.103.0/24 (Android TV, iPhones, Apple TVs) that all can stream full ‘Original Quality’ 4K without a single issue. It only seems to affect the web player.
The server treats data as LAN and WAN differently in different situations. The request log above is only indicating that the request is not on the same subnet as the NIC on which the request arrived. That’s why it is labeled as WAN there. The LAN Networks pref only makes the request be treated differently in terms of bandwidth usage.
So you will want to examine more of the log files. In particular, if decision request (/video/:/:transcode/universal/decision) is being treated like it is on the WAN in terms of bandwidth, you will see a log line like the following: Streaming Resource: Adding session … which is using ####kbps of WAN bandwidth. Used is now ###kbps
If this line is not present, the server is treating the request as if it were on the LAN when it comes to bandwidth usage. It will always log a line like Streaming Resource: Added session … when a playback session is created.
Your comments about this seemingly undoing itself appears to me to be a different issue. Clients themselves have their own quality settings for what they deem to be on the LAN and WAN. The client gets a list of IP addresses it should use to connect to the server and it preferentially prefers the LAN connection but if that connection fails it will fallback to the WAN and maybe even Relay. So if it failed to contact the server on the LAN for some reason, it could be using the WAN IP address when trying to playback. Likely this is the situation you are describing.
I have similar log lines to the ones you mentioned from last year when I tried to debug this:
Dec 15, 2019 14:48:03.226 [0x7f6f2cff9700] DEBUG - Streaming Resource: Calculated bandwidth of 4576kbps exceeds bandwidth limit. Changing decision parameters provided by client to fit bandwidth limit of 4000kbps
If this happens again (it’s okay at the moment) I’ll enable debug logging and have a deeper dive for the lines you mention in your post.
Every time I’ve encountered this bug, I’ve manually confirmed with tcpdump that traffic to my Plex server is indeed going over the LAN, so I definitely don’t think it’s failing back to connecting over WAN for whatever reason.
