I’ve run into an issue running Plex on a server that has two IPs. I only want the service to use a single IP for Plex, however, the API insists on presenting both IPs in its list regardless of the fact that only one is actually available.
In the case above the 2xx IP is the one I DO NOT want plex transmitting data on, however, since it is first in the list some devices, especially Smart TVs, only try the first option in the list the result is those clients are broken unless I listen on both IPs.
Now, I do realize the real solution here is having Plex only listen on a single IP, but this is not an option Plex as of yet and I know people have been asking for it for over five years. In lieu of this, would it be possible to have the entries put into the Custom server access URLs section of the server’s networking settings given priority and put at the top of the list. If that were possible then specifying an IP would no longer be needed as I could specify the desired IP or FQDN that I WANT traffic to be on and call it a day.
Indeed @ChuckPa, which is why I was hoping, as something that should be the norm really, these custom URLs could be bumped to the top of that connection list in the API. This way we can make sure the specified addresses are used as primary sources. Honestly, I would think the only connections that would show up in the list when using the custom URL field would be those custom URLs, but this would at least be a good compromise.
Well, this would not be control of the adapters at any level, but more so a slight API change to reflect the intention of the Custom server access URLs option. I don’t care about control of the adapters as I’m perfectly happy firewalling off the adapters I don’t want listened on, but without the API able to reflect that or at a minimum prioritize what I specify as a custom URL this is not even an option.
You may be able to get what you want by disabling remote access and leaving the custom url field populated. This should pull the plex.direct url off of the plex.tv directory
I just wanted to understand a bit better the request here. Plex clients don’t consider the resource list to be in priority order, and in connection testing, perform the testing in parallel, giving priority to the URLs which work first (and then a bit of biasing towards local addresses).
since it is first in the list some devices, especially Smart TVs, only try the first option in the list the result is those clients are broken unless I listen on both IPs
To be clear, if this is true, it’s a very buggy client and we’ll fix it. Can you elaborate?
the real solution here is having Plex only listen on a single IP
There’s an internal issue for it, but it would be helpful for me to understand the root issue here, because it sounds like if clients are behaving correctly that need wouldn’t exist?
The root issue, at least in this case, is a couple of Smart TVs that do not seem to try to connect to anything beyond the first connection. I say this as the first connection in the API was that of the IP I firewalled off and the TV could not see the server. Once I opened the IP back up it worked fine.
To me, this means it is not trying subsequent connections as if it were the TV would still connect. Keep in mind that other client devices were able to connect when the TV could not.
Ultimately, you are correct! If the client would try all connections I would be fine OR if the server prioritized custom URLs I would be fine, but in this case I’m getting no love from either side.
Can you be a bit more specific about the Smart TVs in question, the version of the software on them, etc.? I can walk this right to the teams in question.
I can tell you one is a Vizio, though I can not be sure of the model number. I did have the user try to uninstall the Plex app/channel and reload it to no avail, I can only assume it was the latest version after the install.
I do not have direct access to the device, but I’ll do my best to facilitate any information I can.
Updated
My logs show the device is listed as a Vizio Presto if that is of any assistance.
Further log scraping shows
Device is Vizio Presto ().
Profile is HTML TV App
X-Plex-Version => 3.13.13
X-Plex-Product => Plex for Vizio
X-Plex-Platform => Vizio Presto
Oddly enough, I sat down and tried your suggestion again and, when I disable remote access my second IP is still in the API resources list. It seems to me like disabling remote access is only controlling the first/main IP that plex is using, the IP listed on the Remote Access page. Unfortunately as well, the second IP is being listed before the custom server access URLs still…
@elan so the the IP showing up even though I have disabled remote access is expected? I would think disabling remote access would leave only the custom server URLs in the list or nothing at all. I would not expect it to only remove a single IP from the list of connections in the API. Honestly, if the server removed all IPs when remote access is disabled and only contained the custom server URLs it would fix my issue as well since relying only on the custom server access URLs would allow me to only have a single and accurate listing in the API.
As for the IP bonding, if the IP bonding allowed for a single IP to be utilized by PMS and ensured only that IP shows up in the API, then that would be great. However, being a Plex user for a number of years, I have heard the the IP bonding request for more than 6 years and little has come from it. I’m not saying it can’t happen, as clearly it can, but more so wondering are resources being actively devoted to it at this time?
so the the IP showing up even though I have disabled remote access is expected?
I’m not sure about this, I haven’t tried that combination (custom URL, remote access disabled) before, but I’ll file an issue.
if the server removed all IPs when remote access is disabled and only contained the custom server URLs it would fix my issue as well
There is still something strange going on, because I talked to the team and it should be treating all remote connections identically, and testing them all, so as long as one works, you should be fine.
wondering are resources being actively devoted to it at this time?
The issue has been filed internally for a while, and recently we’ve had some activity and UX input on it.
The Smart TV application parses the three Connection elements, top down, into a list of connection information.
Next our connection testing logic tests all 3 connections. After each connection test complete we sort all connections with successful connection tests. The first connection in the sorted list is then used for communication.
The sort logic takes into account the properties of the connection. Is it a local connection? Is it a secure connection? Is it shared? Etc. In this case the connections are identical to our sorting logic:
Each is HTTP (protocol="http")
Each is remote (local="0")
When the original parsed list is sorted no items in the list change position. Hence we use the first Connection each time.
For context, why is it important to you that traffic comes through the FQDN?
