Plex Server from SHIELD only available indirect (or often not at all)

Plex Media Server NAS & Devices
1

Hey folks. Recently, I started having issues using the Plex Server running on my Shield. I generally connect from an Android tablet, and the tablet stopped showing my On Deck, Recently Added, and similar sections. Instead it would simply say “Open the Navigation Menu and select a library entry to view content.” If I choose a library, it spins for a very long time before eventually displaying a screen with no contents.

In doing some troubleshooting, I tried going to the Shield directly (http://192.168.164.3:32400/web) which also results in an endless spinner in my browser. This is true on several different computers, including one connected directly to the network switch as the Shield.

Trying with curl, I get this:

$ curl -v 192.168.164.3:32400/web/index.html
*   Trying 192.168.164.3...
* TCP_NODELAY set
* Connected to 192.168.164.3 (192.168.164.3) port 32400 (#0)
> GET /web/index.html HTTP/1.1
> Host: 192.168.164.3:32400
> User-Agent: curl/7.56.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Accept-Ranges: bytes
< Connection: Keep-Alive
* Recv failure: Connection reset by peer
* stopped the pause stream!
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
$ curl -v 192.168.164.3:32500/logging
*   Trying 192.168.164.3...
* TCP_NODELAY set
* Connected to 192.168.164.3 (192.168.164.3) port 32500 (#0)
> GET /logging HTTP/1.1
> Host: 192.168.164.3:32500
> User-Agent: curl/7.56.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Max-Age: 1209600
* no chunk, no close, no size. Assume close to signal end
<
* Recv failure: Connection reset by peer
* stopped the pause stream!
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
2

This even gets weirder. Tonight I realized that even when I’m watching content on the Shield which is running the server, it says “Direct Connection Unavailable”. There’s something really bizarre going on if it can’t talk to itself directly, right?

3

After further testing, it appears that this is limited to Android clients on the local network. Other Plex Servers on the local network work fine. (Mac, WD My Passport Pro, Linux)

Other clients (Mac OS, Browser, Linux, PS4, Plexamp) all can connect to the Shield server with no problem on the local network.

Android clients can not connect to the Shield server only on the local network. If I turn off Wifi on my phone, it connects to the Shield immediately with no problems.

4

@akraut said:
After further testing, it appears that this is limited to Android clients on the local network. Other Plex Servers on the local network work fine. (Mac, WD My Passport Pro, Linux)
Why aren’t the MAC and Linux servers shown in your screenshot? Are you sure you’re using the same account for server and clients? I would suggest logging out of your server then back in and relinking the Shield client.

5

This morning I opened the app on my phone, which was still viewing the TV section from last night, and swiped down to refresh. Here are logs of that refresh from both the client and the server as well as a screenshot of the result of that refresh and a screenshot from my browser viewing the same section. Both clients, phone and web, are on the local network via wifi. (I even disabled LTE data on my phone for this testing.)

Phone Client: v6.11.0.3079 (b66a1134)
Web Client: v3.32.2
Shield Client: v6.11.0.3079 (b66a1134)
Shield Server: v1.10.0.4523 (got this from the web settings screen)


6

Is your Shield set to use a static IP? This can happen is the IP changes. Your phone cached the previous IP and is still try that. Refresh only updates the content, it does not recheck if your server is actually available. Change to another server and back, which will then update the IP it will look for.

Edit - Your PMS logs only have 12 seconds of data. Nothing in there to help.

7

The Shield does have a static DHCP lease. Changing between servers doesn’t seem to change anything. I’ll also try uninstalling and reinstalling the app from my phone this evening. However, what’s strange to me is that this happens on all my android clients. I also have a Pixel tablet and both behave exactly the same.

There were no log entries for hours before the section I snipped and nothing after. However, the log entries that are there are showing the correct ip and port for the Shield. 192.168.164.3:32400 is correct for the shield. 192.168.164.101 is my phone.

I can clear logs, restart everything, and get you fresh logs this evening.

8

Your client log says your phone is trying to contact your server at 192.168.164.3:32400 but it got no response.

Your server log shows some device checking in at 192.168.164.167. Make sure you don’t have the WiFi enabled on your Shield. It’s possible something happened to the ethernet connection so it switched to WiFi but doesn’t switch back.

Edit - Maybe your logs were actually helpful. :smile:

9

Ok, so here’s something curious…

I borrowed a chromebook from work and wiped it. Took it home just now and logged in with a guest account. So it’s connected to my wifi network with no cookies or plugins. Go to https://app.plex.tv/desktop and login and it sees the following server list:

  • MyPassport - Nearby (Padlock)
  • Plex Cloud - Remote (Padlock)
  • SHIELD - Unavailable (Warning Triangle)
  • Cloud Sync - Cloud (Padlock)
  • Friend’s Server - Remote (Padlock)
  • News - Online

When I choose SHIELD, it says ‘Unable to connect to “SHIELD” securely.’ So I choose ‘Allow once’. Now it spins for a bit then loads my Libraries, Live, Online Content, etc. But the dashboard spins for a while before saying ‘There was an unexpected error loading the dashboard’. In the Chrome Dev Tools, I can see requests to the SHIELD spinning and/or timing out.

As an experiment, I opened a new tab and loaded http://192.168.164.3:32400/ which loaded the XML super fast. Open a 3rd tab and load http://192.168.164.3:32400/web which spins for minutes before eventually ending in ERR_CONNECTION_RESET from Chrome.

Now, here’s an interesting log snippet. In it, you can see both of these new tabs, but if I’m reading these right, SHIELD thinks everything loaded just fine. But curiously, if I go back to the XML tab, it was still trying to load the favicon.ico for almost 7mins before failing with a connection reset. Also, the 302 redirect from /web to /web/index.html worked, because that’s what my browser shows in the URL bar, but the loading of index.html did not.

Dec 20, 2017 15:25:28.727 [16395] DEBUG - Request: [::ffff:192.168.164.157:34254 (Allowed Network)] GET / (8 live) GZIP Signed-in
Dec 20, 2017 15:25:28.731 [6262] DEBUG - Completed: [::ffff:192.168.164.157:34254] 200 GET / (8 live) GZIP 4ms 1479 bytes (pipelined: 1)
Dec 20, 2017 15:25:31.425 [16395] DEBUG - Request: [::ffff:192.168.164.157:34254 (Allowed Network)] GET /favicon.ico (8 live) GZIP Signed-in
Dec 20, 2017 15:25:31.464 [16395] DEBUG - Content-Length of /data/user/0/com.plexapp.mediaserver.smb/Resources/Plug-ins-648bc61d4/WebClient.bundle/Contents/Resources/favicon.ico is 5430.
Dec 20, 2017 15:25:31.473 [6263] DEBUG - Completed: [::ffff:192.168.164.157:34254] 200 GET /favicon.ico (8 live) GZIP 48ms 5430 bytes (pipelined: 2)
Dec 20, 2017 15:25:32.665 [16276] ERROR - Error issuing curl_easy_perform(handle): 28
Dec 20, 2017 15:25:32.666 [16276] DEBUG - HTTP simulating 408 after curl timeout
Dec 20, 2017 15:25:35.675 [16419] DEBUG - Request: [::ffff:192.168.164.157:34262 (Allowed Network)] GET /web (9 live) GZIP Signed-in
Dec 20, 2017 15:25:35.678 [6263] DEBUG - Completed: [::ffff:192.168.164.157:34262] 301 GET /web (9 live) GZIP 3ms 236 bytes (pipelined: 1) -> http://192.168.164.3:32400/web/index.html
Dec 20, 2017 15:25:35.735 [16395] DEBUG - Request: [::ffff:192.168.164.157:34262 (Allowed Network)] GET /web/index.html (9 live) GZIP Signed-in
Dec 20, 2017 15:25:35.735 [16395] DEBUG - Final path: /data/user/0/com.plexapp.mediaserver.smb/Resources/Plug-ins-648bc61d4/WebClient.bundle/Contents/Resources/index.html
Dec 20, 2017 15:25:35.737 [16395] DEBUG - Content-Length of /data/user/0/com.plexapp.mediaserver.smb/Resources/Plug-ins-648bc61d4/WebClient.bundle/Contents/Resources/index.html is 4238.
Dec 20, 2017 15:25:35.739 [6262] DEBUG - Completed: [::ffff:192.168.164.157:34262] 200 GET /web/index.html (9 live) GZIP 5ms 4238 bytes (pipelined: 2)

I’ve attached my full server log file, which also includes the stuff I posted earlier this morning.

10

You need to restart PMS on the Shield and get me a new log showing when it is loading. 2 things I notice though.
1 - Looks like you have the “Enable server support for IPv6” on. I would suggest turning that off to rule out any IPv6 issues.
2 - Do you have 192.168.164.0 in your setting for “List of IP addresses and networks that are allowed without auth” or under “LAN Networks”. Do you have an odd network setup that you need to enable these features?

11

I did have IPv6 enabled, which I just turned off. I do not have the local subnet listed in either of those settings. I tried it for a hot minute while debugging, but took it back out about a week ago. Other than using one of those mesh wifi systems (Amplifi) I don’t think my network is “weird” for any reason. Also, if I read the docs right, the local subnet is automatically in the “lan networks” list by default, sorta, right?

New log is attached. After the server started up fully, I opened app.plex.tv/desktop again on that same chromebook and got a message that I was not directly connected. SHIELD show shows in my server list as an Indirect server.

12

Logs from the chrome developer console on that client: https://gist.github.com/anonymous/7b13f782a4067333ba90bffede0d8a28

13

Do you have the WiFi enabled on your Shield? Try turning it off. I see your client trying to connect via the WiFi subnet which isn’t working, so it reverts to a relayed connection which then uses the good ethernet route.

14

its about? https://forums.plex.tv/discussion/300440/plex-remote-access-stopped-working#latest

15

We have deployed a fix on our plex.tv side to mitigate this issue in the cases where some Plex Media Server’s are not publishing correctly. This does not affect all users, but for those it does, the issue should now be resolved if you restart Plex Media Server.

16

I restarted my servers to check if the fix from @chrisallen was the issue, but as I suspected this isn’t the same issue.

The tl;dr version is: This isn’t a Plex issue. Anyone using the Amplifi wifi mesh system from Ubiquiti is likely to run into it.

I have 3 servers running at the moment: WD MyPassport Pro Deluxe +, Nvidia Shield (my main server), Netgear ReadyNAS (running ROS6). The Shield and ReadyNAS are connected via Ethernet. the MyPassport is connected via wireless and it seems like the Shield will also fall back to wireless. ( @“MovieFan.Plex” There’s no specific switch to enable/disable wifi on it that I’ve found. So I still need to go in and tell it to forget the wireless network.) All the devices on the network, wired or wireless live in the same IP Subnet. The ReadyNAS also runs a few other services: Logitech Media Server, NZBGet, File Server, etc. Wired devices have no issue accessing everything on the network. Wireless devices seem to only reliably access ports 80, 443 (and a few other things as long as the packet size is under 1k, though this size value fluctuates). So, it seems as though the wireless network has aggressive QoS and MTU window changes. This is the case even if all the nodes are disconnected and there’s only one Access Point.

What’s really strange though, is that the QoS and MTU windowing seems to apply only from the wireless network to the wired network. ie: If the Shield has it’s ethernet connection unplugged, it starts to work fine. I have a support case open with Ubiquiti right now trying to sort it out. However, right now I’m being escalated from the “But you can access the internet fine so what’s the problem?” support level. I’ll continue to update here if/when I get more information.

17

So, just to close the loop here, the problem was an issue with the Amplifi Wireless Mesh system. It should not be resolved on the latest firmwares.