No external access after install of 1.13.3.5223, had to downgrade

A bit of background, have been running Plex on Windows for several years. ISP is FIOS and remote access has been fine up until the latest update. After the install, remote access stopped working. When I went and clicked “retry” on the Server / Remote Access page the message “Fully accessible outside your network” flashed briefly before returning to the error message (sorry, didn’t jot it down).

I have it set to automatically configure my port and checking the FIOS router, I didn’t see anything amiss. Fought with this a few days then finally decided to uninstall and downgrade to 1.11.3.4793. After the downgrade, remote access is now working fine with no other changes being made on my end.

Just wondering if this is happening/happened for anyone else?

Having the same issue. Cannot get remote access to stay connected. Been running PMS for several years.

There was a bug that got introduced in 1.13.3.5223 that resulted in some events being processed more than once in parallel leading to some timing issues in establishing if remote access is working or not. This bug was fixed in the latest beta releases for 1.13.8 - please try that

@sa2000 I updated as you requested but the issue still persist.

Lets get some server logs after a restart and disabling / re-enabling remote access

Keep a time gap between clicking on the buttons

Make sure debug logging enabled beforehand

Settings / server / general / show advanced - debug logging enabled

restart the server
wait 5 minutes
check remote access status
if not working, disable and wait 30 seconds and then enable
after that wait 30 seconds and click retry

do not click retry many times in quick succession

For logs, go through the troubleshooting link in plex web

Would not mind seeing logs also from the version that works.

I actually just downgraded to 4793 cause other people here are saying that works.

How can i get an older version for windows, as i too have lost my connection externally
with the last upgrade and i want to go to one that still works? Help

I just checked this morning and remote access was down again on the latest Beta release but I forgot to re-enable debugging to get logs.

Hi, I have been having this problem since I update to 1.13.8.5395, remote access not reachable. Will be a fix for this? and how I downgrade to a older version as suggested above?

There won’t be any fix if there are no diagnostics provided to help establish if there is an issue and what it is

No known issues with 1.13.8.

Please ensure debug logging is enabled on the server.
Settings / server / general / show advanced
Then check if debug logging is selected. Enable it if not and save changes

To get diagnostics for the problem, please restart the server
Wait 5 minutes and then check the remote access settings page in server settings and also test to attempt access using, for example, a mobile plex app with Wi-fi disabled

If there is a problem, please take. Screenshot and download the server logs and attach the zipped logs file and screenshot

To download logs, settings and look for troubleshooting within manager server in sidebar and then select download logs

1 Like

Thanks for your reply, these are the files you request?

Plex Media (2.2 MB)

any news? still having problems with remote unreachable

Thanks for sending logs.

I have logs for the following - what i need from you is indication as to what time periods Remote Access was down.

v1.13.5.5332 Sep-24 03:19 am to 15:44 pm
v1.13.8.5395 Sep-24 15:45 pm to 17:32 pm
v1.11.3.4793 Sep-24 17:34 pm to 17:40 pm
v1.13.8.5395 Sep-24 17:41 pm to 17:42 pm
v1.13.8.5395 Sep-24 17:43 pm to Sep-26 19:06 pm

I have managed to find all the times when there was an issue with connectivity - but it looks to me like a system problem. There are periods of hiatus where nothing is logged and it is these times when connectivity to the server breaks.

I would like you to check the windows event log through eventvwr.exe and look at both the System and Application event logs for the periods around the times i give below.

You are using uPnP automatic mapping and your logs show success everytime it is refereshed and we refresh the automatic mapping every hour. You can see from this log extract that it is all perfect

Sep 24, 2018 17:43:34.266 [15080] DEBUG - NAT: UPnP, attempting port mapping.
Sep 24, 2018 17:43:37.282 [15080] DEBUG - NAT: UPnP, mapped port <public port> to 192.168.1.153:32400.
Sep 24, 2018 17:43:37.469 [15080] DEBUG - PublicAddressManager: Mapping succeeded for 192.168.1.153:<public port>.

Sep 24, 2018 18:43:31.052 [14388] DEBUG - NAT: UPnP, attempting port mapping.
Sep 24, 2018 18:43:34.074 [14388] DEBUG - NAT: UPnP, mapped port <public port> to 192.168.1.153:32400.
Sep 24, 2018 18:43:34.668 [14388] DEBUG - PublicAddressManager: Mapping succeeded for 192.168.1.153:<public port>.

Sep 24, 2018 19:43:31.051 [12196] DEBUG - NAT: UPnP, attempting port mapping.
Sep 24, 2018 19:43:32.128 [12196] DEBUG - NAT: UPnP, mapped port <public port> to 192.168.1.153:32400.
Sep 24, 2018 19:43:34.262 [12196] DEBUG - PublicAddressManager: Mapping succeeded for 192.168.1.153:<public port>.

and this continues hourly without any error …

Sep 26, 2018 16:43:31.132 [17264] DEBUG - NAT: UPnP, attempting port mapping.
Sep 26, 2018 16:43:34.156 [17264] DEBUG - NAT: UPnP, mapped port <public port> to 192.168.1.153:32400.
Sep 26, 2018 16:43:34.375 [17264] DEBUG - PublicAddressManager: Mapping succeeded for 192.168.1.153:<public port>.

Sep 26, 2018 17:43:31.134 [11896] DEBUG - NAT: UPnP, attempting port mapping.
Sep 26, 2018 17:43:34.150 [11896] DEBUG - NAT: UPnP, mapped port <public port> to 192.168.1.153:32400.
Sep 26, 2018 17:43:34.377 [11896] DEBUG - PublicAddressManager: Mapping succeeded for 192.168.1.153:<public port>.

Sep 26, 2018 18:43:31.137 [9172] DEBUG - NAT: UPnP, attempting port mapping.
Sep 26, 2018 18:43:34.169 [9172] DEBUG - NAT: UPnP, mapped port <public port> to 192.168.1.153:32400.
Sep 26, 2018 18:43:34.391 [9172] DEBUG - PublicAddressManager: Mapping succeeded for 192.168.1.153:<public port>.

So automatic port mapping is working fine for you.
However we have gaps in time in the logs. This could be a symptom of disk errors or other system issues and I am hoping that may be the windows event logs would shed some light on it

Times to check
There is a 7 minute gap here

Sep 24, 2018 20:46:05.084 [14640] DEBUG - Completed: [34.244.6.8:61920] 200 GET /identity (8 live) TLS 6ms 357 bytes
Sep 24, 2018 20:53:17.198 [14628] DEBUG - handleStreamRead code 10054: An existing connection was forcibly closed by the remote host

and 6 minutes gap here

Sep 24, 2018 20:54:09.891 [14628] DEBUG - NotificationStream: Removing because of error
Sep 24, 2018 21:00:28.151 [17632] DEBUG - Statistics: Flushing 2 expired bandwidth entries, 1 expired media entries.

We have 10 minute and 16 minute gaps here

Sep 24, 2018 21:03:27.036 [14640] DEBUG - Completed: [34.244.6.8:15943] 200 GET /identity (7 live) TLS 6ms 357 bytes
Sep 24, 2018 21:13:25.753 [18168] DEBUG - Sync: uploadStatus
Sep 24, 2018 21:29:09.271 [14640] DEBUG - EventSource: Got event [data] '<Message host="45.79.184.41" port="443" command="startRelay"/>'

and 16 minute gap here

Sep 25, 2018 17:43:40.878 [4280] DEBUG - PubSubManager: Updating best ping time for 172.104.217.190 to 18 ms.
Sep 25, 2018 18:00:03.224 [15908] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.020427 seconds: 192.168.1.161 (Philips hue (192.168.1.161))

Looking at more recent entries, we have 10 minute gap here

Sep 26, 2018 18:43:56.047 [14640] DEBUG - Completed: [192.168.1.188:48039] 200 GET /hubs (7 live) TLS GZIP 143ms 8195 bytes (pipelined: 1)

Sep 26, 2018 18:53:38.301 [9060] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.337514 seconds: 192.168.1.161 (Philips hue (192.168.1.161))

and a number of 4 minute gaps here

Sep 26, 2018 18:53:38.968 [13788] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.161 (Philips hue (192.168.1.161))

Sep 26, 2018 18:57:44.815 [14640] DEBUG - handleStreamRead code 335544539: short read
Sep 26, 2018 18:57:44.815 [14640] DEBUG - NotificationStream: Removing because of error

Sep 26, 2018 19:00:15.386 [8884] DEBUG - Statistics: Flushing 2 expired bandwidth entries, 0 expired media entries.

Sep 26, 2018 19:00:46.164 [9060] DEBUG - NetworkServiceBrowser: PLAYER departed after not being seen for 181.947045 seconds: 192.168.1.188

Sep 26, 2018 19:04:21.658 [14628] DEBUG - EventSource: Got event [data] '<Message host="172.104.29.70" port="443" command="startRelay"/>'

So periods to look at within the windows event log are
September 24th 20:30 to 21:30
September 25th 17:30 to 18:30
September 26th 17:30 to 19:10

Other areas to explore is if you have any specific activity / program that kicks in at specific times

Please check your router to see what port mapping you may have added and exist

You are using automatic uPnP mapping and Plex Media Server picked up random ports to map to 32400 using NAT/uPnP but the mapping is being rejected by the router on 192.168.1.1

Sep 26, 2018 02:37:22.550 [10348] DEBUG - NAT: UPnP, attempting port mapping.

Sep 26, 2018 02:37:25.561 [10348] DEBUG - NAT: UPnP, found device <http://192.168.1.1:56688/rootDesc.xml> with private address <192.168.1.7>
Sep 26, 2018 02:37:25.564 [10348] DEBUG - NAT: UPnP, usable device <http://192.168.1.1:56688/rootDesc.xml> with private address <192.168.1.7>.

Sep 26, 2018 02:37:25.567 [10348] WARN - NAT: UPnP, error mapping port 22326, error: The port mapping entry specified conflicts with a mapping assigned previously to another client, controlURL: http://192.168.1.1:56688/ctl/IPConn.

Sep 26, 2018 02:37:25.567 [10348] DEBUG - NAT: PMP, attempting mapping.
Sep 26, 2018 02:37:25.817 [10348] WARN - NAT: PMP, got an error: NATPMP_ERR_RECVFROM.
Sep 26, 2018 02:37:25.817 [10348] DEBUG - NAT: UPnP, attempting port mapping.
Sep 26, 2018 02:37:25.820 [10348] DEBUG - NAT: UPnP, usable device <http://192.168.1.1:56688/rootDesc.xml> with private address <192.168.1.7>.

Sep 26, 2018 02:37:25.822 [10348] WARN - NAT: UPnP, error mapping port 12299, error: The port mapping entry specified conflicts with a mapping assigned previously to another client, controlURL: http://192.168.1.1:56688/ctl/IPConn.

Sep 26, 2018 02:37:25.957 [10348] DEBUG - PublicAddressManager: Mapping failed.

Could you see what is the uPnP mapping table and also any manual port forwards

What is the router make / model?

could you try now to upgrade to 1.13.8.5395 ?
and please provide logs if there is an issue

I think you got it, mines is working now. I was coming to report the same problem…

Debian headless server running plex v 1.13.8.5395-10d48da0d

Thanks…

Netgear Router AC1200, using Genie R6220. Right at this moment the remote access is ON, but I havent dont anything to fix it so I dont know if it is going to be ON from now on, I will reply if it goes down with logs.

Looks ok. When you get the problem again - collect the logs and also a screenshot of this router page

Also see if there are any entries in the Port Forward table

If there are uPnP issues with the router, you could switch to a manually specified public tcp port and have a port forward in the router of that public port to 32400 on 192.168.1.7 and tick the manually specify port box entering the public port you forwarded

It when OFF again, I when to the router page and refresh uPnP then retry connection on remote access and is working again, Im very noob at this router configuration stuff.


Plex Media (1.1 MB)