Server Version#: 1.21.1.3876
Player Version#: 1.26.0.1531-92029e9e (Mac)
I noticed that my “Limit remote stream bitrate” config (under “Remote Access” section) is also affecting my “local” streaming.
Server IP: 172.16.8.222 (confirmed by looking at the config “Remote Access” under “Network”)
Player IP: 10.2.0.246
Gateway between the two networks has IP: “10.254.99.1”
“LAN Networks” is set to: “172.16.0.0/12,10.254.0.0/16,10.2.0.0/24”
The activity dashboard correctly shows every playback session as:
Plex for Mac — <my client network name>
Local (10.254.99.1)
If “Limit remote stream bitrate” is set to “4Mbps (720p)”, every local playback session has “4Mbps” of bandwidth reserved to it - which causes 1080p content to be transcoded to 720p.
When “Limit remote stream bitrate” is set to “Original (no limit)”, no transcoding happens.
Expected behavior: “limit remote stream bitrate” should have no effect in “local” playback sessions.
Another annoying part of this problem is that “Limit remote stream bitrate” only takes effect when “remote access” is enabled: changing the value requires “Save”, “Disable Remote Access” and “Enable Remote Access”.
Expected behavior: “limit remote stream bitrate” should take effect when it is saved, otherwise, it will (a) mysteriously break local playback when “remote access” is enabled and (b) cause confusion when someone is actually trying to set that config (e.g. Set Bandwidth Limits).
“Treat WAN IP As LAN Bandwidth” has no effect on this behavior.
Steps to reproduce:
Change “limit remote stream bitrate” to “320 kbps”
I ran in to this as well. This was fixed by going to your network settings under the LAN option add your IP like 192.168.0.1/255.255.255.0,127.0.0.1/255.255.255.0. This tells Plex that these are local and do not apply any bandwidth limitations.
The dashboard should show the actual IP address of the client, not the gateway address.
Do not list the gateway IP subnet if there are no local clients on that subnet.
Make sure there is no space after the comma between subnets. 172.16.0.0/12,10.2.0.0/24 not 172.16.0.0/12, 10.2.0.0/24
If you remove the gateway IP subnet from the list of LAN networks, what is displayed in the dashboard when you stream from the Mac? Does it show Remote (10.254.99.1)?
Did you set up any routing on the gateway between the 172.16.x.x and 10.2.x.x networks?
@FordGuy61, the network topology is something like:
Docker network (172.16.0.0/12)
LAN network (10.254.0.0/16)
WLAN network (10.2.0.0/24), router has IP 10.254.99.1 in LAN.
Server is in Docker network, Player is in WLAN network. I am also surprised by seeing a Player on IP 10.2.0.246 reported in the activity dashboard as the Wifi router IP (10.254.99.1) in the LAN, and I can only assume the Wifi router is doing some NAT.
There’s no space in the config, and each subnet uses the CIDR notation.
Removing the LAN network (10.254.0.0/16 ) from the “LAN Networks” config makes every playback session to report Remote (10.254.99.1) - which is why it was there in the first place.
I can’t think of any reason why the playback session would be reported as local but would be bandwidth limited besides a bug. That’s why I hope to get some clarification from Plex Staff on this.
@Alucard1, everything is already configured as you mentioned - unless you are suggesting that I should not use a subnet mask notation instead of a CIDR notation.
The activity dashboard is already displaying every playback session as “Local”.
It is just unexpected (at least) that a “local” playback is bandwidth limited when “remote access” is configured.
I suspect this might be due to the fact that Plex uses DNS-rebinding and/or proxy relays to magically improve the user experience to give them direct access via the internet.
I can only speculate that even though the playback session is reported in the UI as “local” (because the player’s IP is included in “LAN Networks”) the bandwidth management subsystem is either (a) ignoring that information, or (b) assuming this is a “local BUT proxied” session because the client IP is not in the same CIDR as the server.
Have you tried a Plex client in the LAN network, 10.254.x.x, with 10.254.0.0/16 in the “LAN Networks” config?
If so, does the Plex dashboard show it as local?
Does it have the same bandwidth limitations as the WLAN devices?
Here’s what I’m wondering…
If a Plex client in the LAN network acts “normal” for a local device, i.e. no bandwidth limits, then the issues with the WLAN devices could be due to how Plex treats devices behind the WLAN NAT router.
If a Plex client in the LAN network has the same restrictions as a device on the WLAN net, then the problem is not due to NAT, but to something else (bug, configuration setting, etc).
I was able to reproduce this behavior on my test Docker PMS installation. I did so by changing it from host to bridge networking and connecting to it from a client on my IoT network (temporary firewall rule to allow traffic).
To begin, I only had my primary network listed in LAN Networks and I limited remote stream bitrate to 320 Kb/s. As expected, the client was seen as remote and the bandwidth was limited. I then added my IoT network to LAN Networks. With this configured, the client was seen as local; however, the bandwidth was still limited to 320 Kb/s.
I restarted the container to see if that would make any difference, but it did not. The client (Plex on an iPad) had been running throughout, so I completely exited it. After starting it again, I saw the expected behavior; the client was seen as local and no bandwidth restriction was applied.
So, if you haven’t already, try completely exiting the client. And, if you haven’t done so, perhaps restart the PMS container. In my case it seems that the client may have been caching information about its location.
For what it’s worth, I can reproduce this at will now but removing the IoT network from LAN Networks, restarting the client, and then adding the IoT network back. And I can then correct it by restarting the client.
If you do not have Plex and the Clients on the same network segment then the plex client does cannot connect to the plex server directly. Your router will try to route the 172 through the internet unless you setup a specific route in your router. Not sure why you are splitting everything up.
