Update 1.16.5.1488 Broke Remote Access

Server Version#: 1.16.5.1488
Player Version#: Several

Since installing Server 1.16.5.1488 yesterday, I’ve lost the ability to connect remotely. Remote connection has been solid for about eight months. Restart of the QNAP NAS and rechecking all IP Addresses/Ports has been done. Is anyone else experiencing issues?

2 Likes

do you know this because the green tick is now a Red Cross or because friends are complaining?
29

I ask excuse I always have a Red Cross for at least 24 hours after an upgrade or restart, but my friends can still stream fine (i.e. do not trust the little red/green cross/tick).

Thank you for response.

Red Cross, but more importantly, I cannot ping the external IP address and port with the canyouseeme.org site. And… I cannot hit my own Plex when remote.

So… it may be that there’s something else wrong (network-wise, i.e. Port Forwarding) but I haven’t changed any of that lately. Will keep experimenting.

1 Like

Check the QTS virtual switch. Their latest firmware beta update corrected a problem where the v-switch would go offline.

1 Like

I am having the same issue after upgrading my Server version to 1.16.5.1554. Mine is installed on the main PC and PMP works fine and have not picked up any issues but all other devices connecting the server, Smart TV, Tablets and Phones all complain that the server is offline. There seem to be a brief moment where it worked on my phone after restarting the server, but lost connection as soon as I opened a series to watch. Firewall settings, WiFi / LAN all ok as other services works perfectly fine.

Main Device: Windows 10 1903 (18362.295)
Server version#: 1.16.5.1554
Player version#: 3.104.2 (Windows), 7.20.0.11992 (a0514e20) (Android - Tablet & Phone), Samsung TV (also new version)

2 Likes

@pgmannel

Please repost in the Windows threads. This is for QNAP servers.

@ChuckPa
Please take a serious look at this – The problem is NOT platform specific… mine is running on Synology.

My Remote Access says it is not connected after trying many diff things (changing ports, removing/adding rules, restarting, etc). My ASUS router has 10 other Port Forward Rules, 5 of them to the same IP address Plex Server is on. Those work 100% and have for a long time. My Plex install is brand new, just bought Lifetime, never installed Plex before.

When you said Main device, Windows
Player: Windows and called out the Plex/web version

This is how I concluded Windows platform.

Please recreate this problem by:
Verify DEBUG logging enabled, VERBOSE disabled.
disabling remote access.
Wait 2 minutes.
Re-enable Remote Access
After it fails,

Download Logs and attach.

Looks like this issue is ‘well known’ and common.

Attached my debug logs here…
Plex Media Server Logs_2019-08-25_15-03-04.zip (4.4 MB)

Reviewing your logs shows me:

  1. PMS got your public IP
  2. Successfully updated Plex.tv with that IP
  3. Then initiated several connection tests (Remote Access enable) which failed. (reachability: 0)
Aug 25, 2019 14:15:32.343 [0x7f4ede88f700] DEBUG - MyPlex: Published Mapping State response was 201
Aug 25, 2019 14:15:32.343 [0x7f4ede88f700] DEBUG - MyPlex: Got response for 7a2daed07b4431b0605fefce27f6b6dafc905901 ~ registered :0
Aug 25, 2019 14:15:32.345 [0x7f4ede88f700] DEBUG - MyPlex: Updating device connections (from timer: 0)
Aug 25, 2019 14:15:32.346 [0x7f4ede88f700] DEBUG - HTTP requesting PUT https://plex.tv/devices/7a2daed07b4431b0605fefce27f6b6dafc905901?Connection[][uri]=http://192.168.2.50:32400&httpsEnabled=1&httpsRequired=0&dnsRebindingProtection=1&natLoopbackSupported=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
Aug 25, 2019 14:15:32.359 [0x7f4f598e3700] DEBUG - Auth: authenticated user 1 as REDACTED@gmail.com
Aug 25, 2019 14:15:32.360 [0x7f4f399e9700] DEBUG - Request: [192.168.2.11:51957 (Subnet)] PUT /myplex/refreshReachability (17 live) GZIP Signed-in Token (REDACTED@gmail.com)
Aug 25, 2019 14:15:32.361 [0x7f4f399e9700] DEBUG - MyPlex: we already have requested a connectivity refresh for async identifier 69329e24-ca11-4e8c-a183-93409eeeee15 which has not yet expired.
Aug 25, 2019 14:15:32.376 [0x7f4f598e3700] DEBUG - Completed: [192.168.2.11:51957] 200 PUT /myplex/refreshReachability (16 live) GZIP 16ms 274 bytes (pipelined: 7)
Aug 25, 2019 14:15:32.400 [0x7f4f595f5700] DEBUG - Auth: authenticated user 1 as aaronlevey@gmail.com
Aug 25, 2019 14:15:32.401 [0x7f4edce31700] DEBUG - Request: [192.168.2.11:51959 (Subnet)] PUT /myplex/refreshReachability (16 live) TLS GZIP Signed-in Token (REDACTED@gmail.com)
Aug 25, 2019 14:15:32.402 [0x7f4edce31700] DEBUG - MyPlex: we already have requested a connectivity refresh for async identifier 69329e24-ca11-4e8c-a183-93409eeeee15 which has not yet expired.
Aug 25, 2019 14:15:32.404 [0x7f4f595f5700] DEBUG - Completed: [192.168.2.11:51959] 200 PUT /myplex/refreshReachability (15 live) TLS GZIP 2ms 274 bytes (pipelined: 1)
Aug 25, 2019 14:15:32.411 [0x7f4f598e3700] DEBUG - Auth: authenticated user 1 as REDACTED@gmail.com
Aug 25, 2019 14:15:32.412 [0x7f4edfd11700] DEBUG - Request: [192.168.2.11:51960 (Subnet)] PUT /myplex/refreshReachability (14 live) TLS GZIP Signed-in Token (REDACTED@gmail.com)
Aug 25, 2019 14:15:32.413 [0x7f4edfd11700] DEBUG - MyPlex: we already have requested a connectivity refresh for async identifier 69329e24-ca11-4e8c-a183-93409eeeee15 which has not yet expired.
Aug 25, 2019 14:15:32.414 [0x7f4f595f5700] DEBUG - Completed: [192.168.2.11:51960] 200 PUT /myplex/refreshReachability (14 live) TLS GZIP 2ms 274 bytes (pipelined: 1)
Aug 25, 2019 14:15:32.429 [0x7f4f598e3700] DEBUG - Auth: authenticated user 1 as REDACTED@gmail.com
Aug 25, 2019 14:15:32.430 [0x7f4ed3159700] DEBUG - Request: [192.168.2.11:51957 (Subnet)] GET /myplex/account (14 live) GZIP Signed-in Token (REDACTED@gmail.com)
Aug 25, 2019 14:15:32.434 [0x7f4f595f5700] DEBUG - Completed: [192.168.2.11:51957] 200 GET /myplex/account (14 live) GZIP 3ms 2414 bytes (pipelined: 8)
Aug 25, 2019 14:15:32.818 [0x7f4f598e3700] DEBUG - EventSource: Got event [data] '<Message address="24.9.51.135" port="32400" asyncIdentifier="69329e24-ca11-4e8c-a183-93409eeeee15" connectivity="0" command="notifyConnectivity"/>'
Aug 25, 2019 14:15:32.818 [0x7f4f598e3700] DEBUG - PubSub: Got notified of reachability for async identifier 69329e24-ca11-4e8c-a183-93409eeeee15: 0 for 24.9.51.135:32400 (responded in 0 seconds)

Are you absolutely certain that canyouseeme.org shows either the UPNP (which I’m not seeing in the logs) or the manual port as open?

1 Like

Okay, will do. Thank you.

I’m also planning to experiment this Thursday with a couple of other devices I am using port forwarding, to try to take out whether it’s Plex-specific or router or dark hidden forces. It’s just coincidental that it happened after the upgrade to latest version, but it all worked minutes prior to that. But technology…never boring!

The problem is PLEX, not hardware specific… I have a Synology, no firewall running on it and my ports are hard coded to port forward.

@ChuckPa … all other apps work 100% on my port forwards to the SAME IP… this MUST be PLEX, yes?

@Ltek

How Plex does Remote Access control is unique.

  1. PMS takes the settings you gave it (if you manually specified a port)
  2. Asks Plex.tv to attempt to contact it on the port (Reachability test)
  3. Plex.tv initiates a “Callback” on that port as an unsolicited connection request (like a remote player).
  4. If it can connect to PMS, the handshake occurs. Plex.tv returns “Reachability 1” (true) to the PMS request (it’s two http servers talking to each other) .
  5. If Plex.tv doesn’t get a reply (black hole from a firewall/router) within the time limit, or gets “Connection refused”, It replies to PMS with “Reachability 0” (fail)

Things which will mess it up (yes, it’s sensitive).

  1. Turning Remote Access ON - OFF - and back ON in rapid succession. This causes overlapping requests due to the delay at the plex.tv end.

  2. I’ve also seen some UPNP modem/routers show one thing but not actually do it. I saw with with a Netgear DSL modem/router. Their UPNP table would fill. It would accept the UPNP request and reply that it did it but the table was full and the port was never ‘opened’. This is one of the reasons I bought my pfSense box.

  3. The other case I’ve seen, which is a PITA to track down, is when multiple ethernet adapters are involved and the return path from modem -> router doesn’t actually come in on the adapter PMS is listening to. This seems to be the more common. It happens a lot in NAS boxes with multiple active eithernet adapters; each with their own LAN IP. I solved this on QNAP two ways which are effectively the same,

a. LACP the active ethernet ports into one address, making it one IP. No chance of wrong port that way.

b. Added the 10 GbE card, made it the default gateway, and unplugged all the 1 GbE ports so they go dark.

Is Plex being fussy, most likely. It doesn’t tolerate less than perfect networking. That’s clear.

With my pfSense handling UPNP perfectly and one ethernet adapter talking to Plex.tv (the 10 GbE port), there is never a problem.

Thoughts? Does this perhaps help by giving an idea what has become fussier since previous? If so, and we can recreate it, we can get it fixed.

Same problem here on PMS Version 1.16.5.1554. Running Windows Server 2019. Been running great for about 6 months then all of a sudden I get a notification that says my PMS is offline. Im running behind a PfSense firewall with port 32400 forwarded. canyouseeme gives an error for said port. I also have an FTP running on the same machine with no problems. Tried to roll back to earlier versions of PMS with no luck. Getting the same error log as Ltek. Not sure where to go from here?

Update to build 1592 (Plex Pass). There are numerous reports in the forum about it.
FYI, This is a QNAP thread.

Updated…no change. Still cant get outside my network. Ok, sorry Ill post this elsewhere.

Yes there are numerous reports because Plex software is broken. Is anyone on the dev team actively trying to fix this problem?

… btw, I’m not sure why you keep saying the thread is about QNAP, when the problem is not caused by the platform OS… it is a Plex bug. I just paid for Plex and I cant use it outside my house. I’d like to get the functionality I paid. The free version of Emby works fine across the internet.

As I have previously stated:

  1. PMS initiates the visibility test to your system and fails.
  2. Why it fails is unknown to me.
  3. I have 6 different PMS systems here, each on different platforms and none of them fail.

I suspect you have a port-forwarding / UPNP problem. mini-upnpd is nortorious for this.
I use pfSense as my firewall/router solution and there are NO issues.

Emby doesn’t use a brokered service (Emby as the DNS broker). You must provide your own.
Plex.tv is that address brokering service.

I have tried disabling UPNP + disabling the ASUS Firewall (which also turns off DDoS protection) + disabling AI Protect … nothing helps.

The failure IS PLEX

ALL other applications (10 in my case) work 100% perfectly through the same firewall/router (single device) the ONLY app that doesnt is PLEX. Even Chrome Remote Desktop (which is brokered) works perfectly to 3 different devices inside my network, from the internet.

If this is a problem Plex devs cannot figure out how to fix, they need to build-in non-brokered access so we can have the functionality we paid for. I dont see any reason I need to have a brokered connection to Plex. I just want it to work… it doesnt work for many of us.

Ok, so be it.
The biggest problem here is that until it can be replicated under a controlled environment, how can it be fixed? Can’t single step through the code/set breakpoints if you can’t reproduce it.

I can’t cause it to happen at all. Synology, QNAP, Chrome, everyone works for me.
I’m sorry but my best isn’t good enough here. :man_shrugging: