My assumption was that that was your server’s upload bandwidth is restriction being applied (however incorrectly). And that we’re trying to determine why that would be the case if the client IP is being reported as local.
The assumption I’ve been operating on (and trying to find evidence of in the logging) is that PMS is treating this as a remote connection even though it is reporting it as local in the dashboard. Presumably this would be because of some vestige of the traversal of multiple networks being detected by the logic which determines locality.
Router 1:
Is subnet 10.2.7.0/24 connected to Router 1?
Router 2
It looks like you need to adjust the static route in Router 2.
You do not need to route 10.2.0.0/16 back to Router 1.
All Router 2 needs is a default route pointing to 172.16.0.1, as that is the only path available.
I believe, based on earlier comments, that router 2 needs to have its default route configured such that it can reach its own Internet provider (or other upstream device?). It’s at another physical location, connected via a PtP wireless connection to the OP’s location. The static routes are intended to route specific traffic in this case. And, as shown in trace route output, traffic from 10.2.0.0 to 192.168.1.0 is routing directly (and correctly).
I notice that you’re using a custom certificate/hostname. Does the behavior change if you disable that? I don’t expect it to help, it’s just an easy thing to test.
I notice this difference -
In the 10.1 URLs file publicAddressMatches="1"
In the 10.2 URLs file publicAddressMatches="0"
So I wonder if either the client or server is using publicAddressMatches to determine if bandwidth limits are added during playback decision-making.
In both client logs, all registered server addresses are tested and all succeed. Good.
In both logs the 192-168-1-15.obscured.plex.direct server address is selected as soon as it responds. Good.
In both logs the [Transcoder] Video (decision) includes "location": "lan", although the maxVideoBitrate constraint is only applied to 10.2.x.x.
And as you showed originally, they both show as “Local” in the dashboad.
So I agree, kinda seems like a bug. I wouldn’t expect the bandwidth limit to be applied for a classified-as-local (lan) connection.
Or at least it’s confusing/surprising! I wonder what else publicAddressMatches might be used for.
@Baschtel14 I assume that the 30 Mbps is provided by the server, correct? If you change to 15 Mbps on the server, without changing any client settings, is that correct?
I agree here. Having looked at the client logs, the client on the 10.2.0.0 network is identifying server host at 192.168.1.15 and connecting to it. Why it is being reported as local in the server’s dashboard but having bandwidth restrictions applied is a mystery.
Yes, per an earlier comment, this is being applied by the server.
That question was to confirm that it tracks with the server setting, and to rule out it being a value that’s configured within the client. I’m 90% sure it’s getting that value from the server.
I’d like to know more about the MDE process. The server may give that value to the client, and the client may compare it with local settings and give it back to the server (as a profile augmentation) during the MDE exchange?
@Baschtel14 Would you be okay with my sharing of your logs with @Volts via private message? They can likely provide additional insight which could prove helpful. I’ve not found anything which suggests anything other than a potential fault in the way Plex Media Server is determining bandwidth restrictions in a multi-lan network environment but additional visibility may help. Let me know, or send the logs you sent to me to them directly. Thanks!
[Edited to add]
Per @Volts’ comment below, the logs have already been provided. Please disregard my comment. (You’re in good hands!)
I just tried it once.
I have set the default route to router 1 on router 2. So router 2 has the same public IP as router 1.
And then 4k direct play works on the network 10.2.1.0. No limits and no transcoding.
But the behavior is not correct in my opinion. If I add the network in Lan networks in the settings and the client can reach the server directly via the local network, then I want to have no restrictions, even if the network has a different public IP address.
That does make sense and I think matches what he’s describing.
But then, what’s the point of the LAN Networks setting?
I totally understand and agree with the security changes Plex made for ... allowed without auth.
But for bandwidth control, it seems like the LAN Networks setting should be the trump card?
(There were some other posts about “why is bandwidth control acting funky for my client on a local VPN? LAN Networks is being ignored.”. I’ll try to find them. I wonder if it’s related.)
You can’t trump something just by saying “this is what I want” when:
You can’t set a netmask which makes it legitimate
It’s more than 1 hop away
It doesn’t have have a gateway.
This whole problem is a network design problem.
In this case, PMS should be on a 10. network with a WIDE netmask to include it all.
( Example: 10.0.0.2/8 - 24 bit subnet with PMS on the first IP below the router)
where PMS is at the top of the heap, not stuck out in right field.
To fix this network is easy but it’s up to the users to manage their own networks.
Make a big subnet
Put PMS in the main subnet and give it a wide subnet mask
The whole network should appear “Subnet FLAT” to PMS.
Commercial networks are multi-hop
Home networks are 99.99% one or two subnets
