I cannot confirm the date but I expect it to be any day now - in next few days
1 Like
Just installed Version 1.19.3.2764 - the issue persists
There is currently an issue with timeouts whilst doing the connectivity tests to establish if remote access is working - I have seen evidence of this from users mainly in New Zealand, Australia, Malaysia and Singapore where there are timeouts on the requests coming in from the Amazon Cloud hosted servers in Europe.
This has been referred to our plex.tv team.
I would like to see more examples of server logs with verbose logging enabled when the remote access goes down whilst the server settings page is open.
Iām experiencing the same thing as of a few weeks ago, latest versions - 1.19.3.2764 (am also on PlexPass) and the issue persists. It usually just drops for a few minutes and then comes back (I have Tautulli notifications enabled for when remote acces goes down). Iāve seen it happen multiple times a day, and some days where it happens only once or not at all, seems very random.
I am in the USA so nowhere near those countires you specify, so hoping my logs will be useful. Enabling verbose logging now.
PS. I have also fully reset my token thinking that may help but it has not.
Also for reference Iām running the offical PMS docker container on unRAID.
WELL THAT WAS FAST! I enabled verbose logging, restarted, and sat on the remote access screen and saw it down/up/down/up
Iāve attached the logs (server was only up for literally few minutes)
Note that Tautulli did not alert because it doesnāt seem like it was down long enough this time to trigger an alert (it has to fail a few times in a row during its test to trigger an alert to me).
If this is enough or not enough, either way let me know so I can leave verbose logs enabled or turn them off. For now Iāll eave them on until I hear back.
Thanks!
Same thing, up-down-up-down. 1.19.3.2764 on Ubuntu 18.04.4. Only access locally. I have done everything short of re-installing. Not sure what to do now.
1 Like
Could you provide verbose logs? They said they need to see more logs from more users. Process is very simple to do.
Thanks - it is the issue of aborted connectivity test requests
This was successful
May 08, 2020 22:13:08.278 [0x153f24be5700] DEBUG - Request: [34.248.59.52:55664 (WAN)] GET /identity (36 live) TLS Signed-in Token (CorneliousJD)
May 08, 2020 22:13:08.278 [0x153f5640e700] DEBUG - Completed: [34.248.59.52:55664] 200 GET /identity (36 live) TLS 0ms 398 bytes (pipelined: 1)
May 08, 2020 22:13:08.558 [0x153f5660f700] DEBUG - EventSource: Got event [data] '<Message address="69.14.xxx.xxx" port="32400" asyncIdentifier="3f6a75b9-23fd-41a1-b09d-70a87496fd8c" connectivity="1" command="notifyConnectivity"/>'
Next one 16 seconds later was aborted / timed out?
May 08, 2020 22:13:24.629 [0x153f5640e700] DEBUG - EventSource: Got event [data] '<Message address="69.14.xxx.xxx" port="32400" asyncIdentifier="4c96abc6-3564-4ba9-be3c-4c4c0d5ff9ba" connectivity="0" command="notifyConnectivity"/>'
May 08, 2020 22:13:28.278 [0x153f5640e700] VERBOSE - We didn't receive any data from 34.248.59.52:55664 in time, dropping connection.
May 08, 2020 22:13:28.990 [0x153f5640e700] VERBOSE - Didn't receive a request from 34.248.59.52:55664: End of file
Next test was ok
May 08, 2020 22:13:44.389 [0x153f25dee700] DEBUG - Request: [34.245.172.51:52866 (WAN)] GET /identity (38 live) TLS Signed-in Token (CorneliousJD)
May 08, 2020 22:13:44.390 [0x153f5640e700] DEBUG - Completed: [34.245.172.51:52866] 200 GET /identity (38 live) TLS 0ms 398 bytes (pipelined: 1)
May 08, 2020 22:13:44.665 [0x153f5660f700] DEBUG - EventSource: Got event [data] '<Message address="69.14.xxx.xxx" port="32400" asyncIdentifier="c08a07df-4f24-49e6-88c7-f432b1c25730" connectivity="1" command="notifyConnectivity"/>'
and an aborted test
May 08, 2020 22:14:04.390 [0x153f5640e700] VERBOSE - We didn't receive any data from 34.245.172.51:52866 in time, dropping connection.
May 08, 2020 22:14:06.766 [0x153f5640e700] VERBOSE - Didn't receive a request from 34.245.172.51:52866: End of file
and next was ok
May 08, 2020 22:14:12.802 [0x153f24de6700] DEBUG - Request: [34.248.59.52:37886 (WAN)] GET /identity (38 live) TLS Signed-in Token (CorneliousJD)
May 08, 2020 22:14:12.803 [0x153f5660f700] DEBUG - Completed: [34.248.59.52:37886] 200 GET /identity (38 live) TLS 0ms 398 bytes (pipelined: 1)
May 08, 2020 22:14:12.950 [0x153f5640e700] DEBUG - EventSource: Got event [data] '<Message address="69.14.xxx.xxx" port="32400" asyncIdentifier="ce97ac0e-5322-4a4c-a826-0b727318c5b2" connectivity="1" command="notifyConnectivity"/>'
This was four days ago - is it still the same ?
Could you get me a traceroute to each of these IP address - to see what delays are for each hop. Traceroute may timeout on some hops
34.248.59.52
34.245.172.51
Well so far today, no drops, but May 9th, 10:01AM down, then 10:02AM up, and then on May 10th 3:35PM it dropped and 3:42PM came back up. Again no drops yet today (that tautulli reports at least, it may be dropping but I have Tautulli set to fail 3 consecutive times on remote access test before alerting me, to reduce the amount of alerts I get)
Here is the traces you requested.
Please let me know if you need anything else from me to help narrow this down.
I DO have verbose logging disabled again for now but can easily turn it back on and run more tests, etc. Just let me know, thanks!
tracert 34.245.172.51
Tracing route to ec2-34-245-172-51.eu-west-1.compute.amazonaws.com [34.245.172.51]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Gateway-Basement [10.0.0.1]
2 16 ms 10 ms 13 ms d192-24-1-192.try.wideopenwest.com [24.192.192.1]
3 9 ms 9 ms 12 ms dynamic-76-73-172-1.knology.net [76.73.172.1]
4 18 ms 15 ms 18 ms 76-73-165-176.knology.net [76.73.165.176]
5 24 ms 28 ms 18 ms dynamic-75-76-35-3.knology.net [75.76.35.3]
6 22 ms 18 ms 17 ms dynamic-75-76-35-51.knology.net [75.76.35.51]
7 39 ms 16 ms 17 ms dynamic-75-76-35-8.knology.net [75.76.35.8]
8 53 ms 56 ms 31 ms chi-b21-link.telia.net [62.115.63.86]
9 * * * Request timed out.
10 * * * Request timed out.
11 116 ms 119 ms 118 ms ldn-b1-link.telia.net [62.115.121.29]
12 112 ms 119 ms 115 ms a100-ic-328647-ldn-b1.c.telia.net [213.248.99.217]
13 120 ms 127 ms 122 ms 54.239.100.247
14 118 ms 124 ms 115 ms 54.239.101.161
15 * * * Request timed out.
16 128 ms 133 ms 135 ms 54.239.44.150
17 * * * Request timed out.
18 144 ms 121 ms 136 ms 52.93.6.242
19 130 ms 130 ms 152 ms 52.93.101.11
20 156 ms 128 ms 154 ms 52.93.101.42
21 142 ms 128 ms 154 ms 52.93.7.155
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
tracert 34.248.59.52
Tracing route to ec2-34-248-59-52.eu-west-1.compute.amazonaws.com [34.248.59.52]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Gateway-Basement [10.0.0.1]
2 14 ms 15 ms 13 ms d192-24-1-192.try.wideopenwest.com [24.192.192.1]
3 22 ms 16 ms 13 ms dynamic-76-73-172-1.knology.net [76.73.172.1]
4 13 ms 10 ms 22 ms 76-73-165-176.knology.net [76.73.165.176]
5 20 ms 10 ms 14 ms dynamic-75-76-35-3.knology.net [75.76.35.3]
6 39 ms 26 ms 42 ms dynamic-75-76-35-51.knology.net [75.76.35.51]
7 22 ms 24 ms 22 ms dynamic-75-76-35-8.knology.net [75.76.35.8]
8 36 ms 36 ms 31 ms chi-b21-link.telia.net [62.115.63.86]
9 * * * Request timed out.
10 121 ms 126 ms * ldn-bb3-link.telia.net [62.115.113.21]
11 119 ms 137 ms 120 ms ldn-b1-link.telia.net [62.115.121.27]
12 * 117 ms 117 ms a100-ic-328647-ldn-b1.c.telia.net [213.248.99.217]
13 132 ms 125 ms 124 ms 54.239.100.201
14 122 ms 118 ms * 54.239.101.43
15 * * * Request timed out.
16 130 ms 129 ms 133 ms 54.239.47.6
17 * * * Request timed out.
18 127 ms 126 ms 133 ms 52.93.6.248
19 132 ms 132 ms 131 ms 52.93.101.33
20 136 ms 131 ms 130 ms 52.93.101.16
21 133 ms 128 ms 125 ms 52.93.7.133
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
Turn off the VPNā¦ if it works thenā¦ follow these instructions.
@benyeager was this in resposne to someone else or me? Iām not running the server through a VPN at all.
@sa2000 do you need any other tests/logging from me?
Iām sure you know but the issue does continue still right now.
Thanks - have all I need at the moment. Most affected users are further away from the Amazon Cloud servers that are located in Ireland
The impact of this is that the status indicator is wrong indicating failure when it is actually available.
Same thing here. Continuously dropping remote access. Itās not just the indicator for me, remote access is not working (cannot play movies remotely).
Version: 1.19.3.2764 / Docker
EDIT: I had a separe hw-transcoding error which caused playing issue. I fixed it and remote play works. It still continually disconnects but works.
1 Like
That would be something else. Would need server debug logs covering the time when it drops out. If you use a dynamic automatically assigned port for remote access then that gets refreshed / re-instated in the router every hour and may be an error is arising. We refresh the mapping of the port every hour. If you use a port forward and manually specify the public port then the only periodic action is to check if the public IP has changed.
Hi, same issue here unfortunately. I am not an expert but I have tried different processes but with no luck. My remote access will go down after few seconds regardless.
Was hoping you could take a look at my log files maybe you can figure out a way to solve this headache, thanks!
Plex version 1.19.3.2764
OS: Windows 10 64bit
{Note: This post covers only a possible DNS/Server issue ā Reconnects and Disconnects are happening consistently. This covers testing of specific servers when connecting and disconnecting when the DNS name plex.tv resolves to a specific address.}
The testing performed was done by hard static set of the domain address plex.tv through a host file (eliminating the round robin or distributive DNS method in place) to One of Three possibilities. During the testing the 99.80.242.242 address behaved differently than the other 2 addresses. Both when doing a simple connect and when moving between IP addresses (therefore moving between servers).
What was observed: two error messages (noted below). The PMP message was a warning while the CURL was noted as an error within the plex logs (these are likely expected error messages). When moving between 99.81.213.165 to 99.80.231.223 and vice versa the behavior was consistent. However, when moving between the other IP address to the two previously mention there were some anomalies. Repeat attempt to connecting were required, when moving to 99.80.242.242 from the other two IP addresses. Doing the reverse could cause the Remote Access to be disabled. Inconsistently you may have to manually go in and re-enabled the setting. This behavior did not happen with the other two IP addresses when switching back and forthā¦
Server Version#: 1.18.4.2171 -> Current
Player Version#: No issues with WebBased Players, all other client players (Roku, Firestick, PS4, IOS Android and Various TVs have issues seeing Plex Server).
Manual Open Port 32400 - When Plex reported Remote Access lost, remote testing was still able to access port 32400.
{Common Events Occurring - Disconnect/Reconnect]
Error issuing curl_easy_perform(handle): 28
NAT: PMP, got an error: NATPMP_ERR_RECVFROM.
These seem to be common messages when disconnecting and reconnecting.
[Plex.tv Network]
99.80.242.242 - Amazon Ireland Dublin Range- 99.80.0.0-99.81.255.255 Net: /16
Reverse ec2-99-80-242-242.eu-west-1.compute.amazonaws.com
99.81.213.165 - Amazon Ireland Dublin Range- 99.80.0.0-99.81.255.255 Net: /20
Reverse: ec2-99-81-213-165.eu-west-1.compute.amazonaws.com
99.80.231.223 - Amazon Ireland Dublin Range - 99.80.0.0-99.81.255.255 Net: /20
Reverse: ec2-99-80-231-223.eu-west-1.compute.amazonaws.com*
[Plex.Direct]
82.94.168.7 - Haarlemmermeer, 07, Netherlands
(Possible Use: Validate Plex tokens based on logs)
[Plex Authentication Server]
52.16.207.132.
[Plex Name Servers]
ns-282.awsdns-35.com IP: 205.251.193.26 Loc: Amsterdam NL
ns-1005.awsdns-61.net IP: 205.251.195.237 Loc: St.Johns CN
ns-1566.awsdns-03.co.uk IP: 205.251.198.30 Loc: LA CA US ā (UK domain in Cali ā humm)
ns-1342.awsdns-39.org IP: 205.251.197.62 LOC: DallasTX US
The system is very unstable externally. Great that the DNS servers are distributive, but the Plex servers themselves all appear to be in Ireland. I suspect that there is a provisioning issue, the servers doing the validating are not in a consistent state, or there is a coding problem with how security is being done (given these issues do not seem to have appeared until after the recent security changes).
[Process of obtaining token identity]
submit API request to plex.tv with asyncidentifer
Get Plex Token from 52.16.207.132 Port 44082
Set public IP via response from plext.tv/pms
Get reuest to https://External-IP.token.plex.direct:port/identity
Reponse validates with:
HTTP 200 response from GET https://external-ip.plex-generated-token*.plex.direct.portnumber/identity
This process can be seen each time you disconnect and reconnect.
Additional Note: Tautulli does seem to exacerbate the problem, disabling this had a notice effect on the number of reconnects. I systematically rolled back versions until 1.18.4.2171. This appeared to be the most stable at the time. However results have been inconclusive more detail packet analysis and log review are required.
When connecting externally with IOS/Android Device: They would only connect via relay. (Version 8.0.1.17410 current rev for Android)
When connecting through the Plex App Through these same devices via a browser like chrome there was no issue. Relaying does appear to at least get someone connected, but this is not a desirable fix.
FWIW - As per a comment in the other thread, I disabled the DDoS feature on my Asus RT-AC68U router, and the connection issues mostly went away.
I had also experimented with installing a previous 16.x build of Plex where the remote connection problems were less unstable, so there may be a combination of something that changed in a recent router firmware, and something that changed in Plex over the past few months, as prior to a couple of months ago the remote access was mostly ok, it became totally hopeless in the past month or so (unsure when as it hasnāt been used much during the lockdown).
What I find curious is that there does not seem to be an issue when using the plex.tv website UI to access media. Of course given you are on within the same network as the validation systems, one would expect things to work there. There is an obvious experience difference when using other hardware/software outside of the plex.tv network. Android/IOS phones Roku Firestick all have seen issues (personally tested) when trying to access media externally. The mobile devices when using a web based browser to plex.tv do not experience the same issues as the custom applications for those devices. The fact there is a different experience between the two (one where you can access media, and one you cant) on the same device/connection should be a starting point for Plex software/network team to look at (if they havent already).
Given the shear volume of disconnect reconnects for myself and multiplying that across the spectrum of all plex media servers I have to wonder what state the authorization servers are in (getting hammered by requests). That has been the one sticking point I have personally with Plexās. That desire to maintain control over their product at the detriment to their user base (I am not suggesting they not get paid for their efforts, subscriptions should cover that). I find it questionable about the amount of meta-data gathered (read the ToS) Such things are ripe for abuse. Couple that poor UI āenhancementsā and trying to monetize the product by injecting unwanted āfeatureā sets like Crackle (undoubtedly there is a revenue stream here for Plex) I have to wonder at the long term strategy they are planning. ----- Nevertheless while other products are out there, none are as well supported by other vendors making it the only game in town.
i dont have troubleshoot data to share, but i can say that starting beginning of may i kept getting daily remote access down/up messages from Tautulli. it didnt disturb me all that much since i didnt get reports from external users that they were having issues. nor was the message that frequent that i was too bothered looking into the problem.
Interesting event: Anyone else who is reading this thread who has had issues check it out now. Without making any modification to my network or settings within Plex (since yesterday) what I have noticed is a a very fast disconnect reconnect (and it could be just the local UI interface). Something has changed, also Iāve noticed that PlexRelay.exe is not longer kicking off. Previously this was used by remote clients to access media. Iāve renamed the exe to inhibit the use, and it still continues to work. (edit- Plex continues to allow connections and media access even though the Plexrelay.exe was renamed and the process terminated) ā¦ In addition to thatā¦ the logs are no longer showing the host names or IP addresses for token validationā¦ I find that curious.
I wonder if Plex will fess up or if the issue what with Amazon or whatever, seems to have cleared up ā¦ for the moment. I will continue to log this, was about to change networks to my Palo to get a better view of whats going onā¦ humm still may do that.
