Server IP changed - now a whole host of problems

EDIT with a new development at the bottom, but leaving the rest for context

Server Version#: 1.21.0.3711
Player Version#: Plex for Samsung 5.5.1

I recently replaced my router. It used to issue 192.168.29.x IPs, and the rack server running Docker with a Plex container was 192.168.29.200. Everything worked fine until I swapped out for a new router which issues standard 192.168.1.x IPs. I set the server back up with a new static IP of 192.168.1.200. This is where the problems began.

Initially, the issue was that my Plex apps - TV or Web App - could not see the library at all, presumably looking for the old IP. I reset the TV app and also tried resetting the Web app by removing those parameters from Preferences.xml. I also redeployed the container with the latest Plex update. No luck until I got a new Claim Code and replaced the old one in the Dockerfile. Now my libraries show up in the Web App, but strangely, I am asked to configure what Libraries I want to appear every single time. Playback also takes a few beats longer than it used to.

However, on the TV App, everything is tremendously slower, and while I can see my libraries, I cannot see their cover art - the posters are all black/blank. When I try to play something, it either doesn’t play, saying “media file format not supported” for a file I know played just fine on the previous configuration. About 75% of the time, I can hear the fans on my server kick into overdrive while the TV is Buffering the stream, and top shows the Plex Transcoder process using north of 750% CPU.

Strangely enough, the TV also shows that it is accessing my library via “Remote.” I do not know why it wouldn’t use the local, private IP, which is how it used to connect in the previous configuration. I’ve reset the TV app a few times and still get the same result.

Both my TV and my laptops using the Web App are all connected through the same network, which looks like this:

Clients -> UniFi Access Point -> Catalyst Switch (flat switching, nothing special) -> pfSense Router -> Frontier Modem -> Coax

Every client gets a 192.168.1.x IP. Everyone is DHCP besides the server. Everyone is on the same subnet.

I don’t have any other Internet issues on this network - even my other containers work fine, including an Emby container with other media - just Plex isn’t behaving. Port 32400 is open on anything with a firewall - the Frontier Modem forwards it to the pfSense network, and in addition to a specific pfSense rule allowing it through to the 192.168.1.200 IP, I also have an any-any rule allowing pretty much anything to pass through pfSense, because I don’t really need the firewall capability. The Frontier rule forwards TCP and UDP traffic. The pfSense rule allows everything through, regardless of protocol.

It obviously seems that the TV and the server are communicating, or the process wouldn’t be kicking into high gear and making my fans go wild. However, the server is apparently now struggling to send information back to the TV in a usable format. I’ve tried tinkering with the Direct Play and Direct Stream settings, but this makes no difference. I also cannot figure out why the artwork won’t load, and why the TV is committed to trying to go out to access my server remotely, rather than just going straight across the LAN.

Any help would be appreciated. I did not find any useful logs besides the below from the media server logs, all around the time I was trying to get something to play on the TV. The Transcoder logs don’t show anything special, it looks like normal Session logs with the play header, etc.

Dec 07, 2020 10:28:51.383 [0x7fbdc8ba3700] ERROR - Unknown metadata type: folder
Dec 07, 2020 10:30:51.816 [0x7fbdc8ba3700] ERROR - Unable to find client profile for device; platform=Tizen, platformVersion=3, device=17_KANTM_UHD_BASIC, model=UN65MU6290
Dec 07, 2020 10:31:11.864 [0x7fbdc8ba3700] WARN - [Transcode] Got a transcode session ping without a session GUID (or with an invalid one).
Dec 07, 2020 10:31:31.916 [0x7fbdc8ba3700] ERROR - Unable to find client profile for device; platform=Tizen, platformVersion=3, device=17_KANTM_UHD_BASIC, model=UN65MU6290
Dec 07, 2020 10:31:51.948 [0x7fbda4ff9700] WARN - Got a request to stop a transcode session without a session GUID (or with an invalid one).
Dec 07, 2020 10:36:51.330 [0x7fbdb8ff9700] INFO - [PlexRelay] Allocated port 29163 for remote forward to 127.0.0.1:32401
Dec 07, 2020 10:36:53.152 [0x7fbdb8ff9700] WARN - QueryParser: Invalid field 'contentDirectoryID' found, ignoring.
Dec 07, 2020 10:36:53.152 [0x7fbdb8ff9700] WARN - QueryParser: Invalid field 'promoted' found, ignoring.
Dec 07, 2020 10:36:53.155 [0x7fbdb8ff9700] WARN - QueryParser: Invalid field 'contentDirectoryID' found, ignoring.
Dec 07, 2020 10:36:53.155 [0x7fbdb8ff9700] WARN - QueryParser: Invalid field 'promoted' found, ignoring.
Dec 07, 2020 10:36:53.673 [0x7fbdc8ba3700] INFO - AutoUpdate: no updates available
Dec 07, 2020 10:36:56.092 [0x7fbdc8ba3700] WARN - QueryParser: Invalid field 'contentDirectoryID' found, ignoring.
Dec 07, 2020 10:36:56.098 [0x7fbdc8ba3700] WARN - QueryParser: Invalid field 'contentDirectoryID' found, ignoring.
Dec 07, 2020 10:40:28.332 [0x7fbd53fff700] WARN - QueryParser: Invalid field 'contentDirectoryID' found, ignoring.
Dec 07, 2020 10:40:28.334 [0x7fbd53fff700] WARN - QueryParser: Invalid field 'contentDirectoryID' found, ignoring.

New development:

Disabling Remote Access makes the TV work. Posters/artwork load fine, I can stream files just fine. So now what I need to know is… why was the TV app so committed to trying to access the server remotely when it was an option, albeit a malfunctioning one… but then when I took that option away, it goes, oh, okay, I can access your library over the LAN just fine? You’d think the failover would be the other way around.

In pfsense you can set any network you wish for the LAN interface. You are not required to use the default 192.168.1.0/24

You should have reset this to:

192.168.29.0/24

See Interfaces | LAN in the GUI or use the Console 2) Set interface(s) IP address

Yeah, in hindsight I should have just done a drop-in replacement and set everything back up on 29.x, but at this point, I’ve already reconfigured everything to be on 1.x, so here I am.

I am updating the post though with a strange development: Disabling Remote Access makes the TV work. Posters/artwork load fine, I can stream files just fine. So now what I need to know is… why was the TV app so committed to trying to access the server remotely when it was an option, albeit a malfunctioning one… but then when I took that option away, it goes, oh, okay, I can access your library over the LAN just fine? You’d think the failover would be the other way around.

I’ve seen this issue when installing the server on a different PC but using the same server name. The result would be similar to your situation.
You may have to remove your existing Authorize Devices from the server in settings.
Try one device and see if that works.

Yep, I removed them all, including, accidentally, the one I was logged in on, which logged me out. But I’ve definitely done a clean sweep of that section and re-paired the TV with the account.

So, everything is ok now?

Not because of removing Authorized Devices. I did that a few days ago and it didn’t change anything.

I updated the OP that disabling Remote Access seemed to do the trick, but I want to understand why - both for my own edification, and also so that I can turn it back on at some point. Right now, disabling Remote Access is, oddly, the fix for watching things locally… but someday, I want to be able to watch things remotely, and I’d have to re-enable that functionality, which will apparently break local watching.

1 Like

Your issues could have been cause by a couple of things. Usually, the most likely would be DNS rebinding protection on your router causing local clients to be unable to resolve the IP address of your server by its custom *.plex.direct FQDN. However, that wouldn’t necessarily explain why disabling remote access caused connectivity to be restored. Have a look at this article, specifically the “pfSense DNS Resolver” section:
https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/#toc-4

The article itself is an interesting read as it describes how Plex enables secure, certificate-based connections for all servers. That specific section describes how to tell pfSense’s DNS resolver to carve out an exception for DNS rebinding for *.plex.direct.

Try configuring pfSense as described there, re-enable remote access, and see if that helps.

Outside of that is the possibility that the connection information stored by Plex’s servers didn’t catch up with your network renumbering in a timely manner. You can check to see where they think your server can be contacted at by browsing to:

https://plex.tv/api/resources?X-Plex-Token=your_plex_token

This article describes how to find your Plex token. You can also find it in your Preferences.xml file (PlexOnlineToken). Don’t post that value here.

That page will result in an XML document with information about all your Plex devices. Your server should be listed at the top and should have some connection information shown. Check the IP address shown there for the local="1" entry and see if it shows the new IP address (you can check the local="0" entry, too).

I’ll try the DNS fix a little later and report back. As for the Token, it returns XML that shows two IP addresses for each client; 192.168.1.200, and 172.17.0.7. The former is the LAN IP of the rack server, while the latter is the IP of the container itself inside of Docker’s little bridge network. I’m actually a little surprised it can even see that far down.

That’s normal when you’re using bridged networking. If you instead used host networking it would just show the host IP address.

Something else to check is under Settings -> Network in the web client. Make sure you’ve set/updated the “LAN Networks” setting to reflect the network renumbering. If you don’t it may treat all clients on 192.168.1.0/24 as remote and apply any remote bandwidth restrictions you have configured to them.

Someone else/some documentation suggested that, but I actually don’t have that in my Settings > Networks area, unless I’m just not looking hard enough. The only text fields I have are 3 relating to certificate encryption, and then Custom Server Access URLs, and List of IP addresses that are allowed without auth.

That’s my mistake, sorry. It’s a Plex Pass feature and I didn’t notice that you’re not subscribed.

Is there a reason you’re using bridged vs. host networking for this container? It’s not an issue with host networking as the Plex container will share the host’s IP address.

Not particularly. I’m not much of an advanced networking guy, so I tend to use this things as they come out of the box. Portainer set me up with Docker using the bridge network, so I’ve just kind of kept it that way. I really only have pfSense because my ASUS router bit the dust, and I had spare hardware lying around.

Not being able to configure LAN networks likely won’t cause any problems since you can’t configured bandwidth restrictions on the server anyway. Those settings are also gated by a Plex Pass subscription. It may just be annoying seeing the location displayed as remote in the dashboard.

Well, it shows as Nearby now, having somehow changed to be able to find it locally once Remote access was disabled. When Remote access was previously enabled, it was seeing it as Remote. That’s what I’m trying to figure out… why the routing for finding it locally apparently works when remote is disabled, but doesn’t when it’s enabled.

That said, I haven’t tried re-enabling Remote access now to see if this was a one-time issue or if it’s reproducable, mainly because I don’t want to break what appears to be currently working… at least not until post-COVID when I’m traveling again and need to access the library remotely.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.