Remote access failure

Plex Media Server Remote Access
1

Server Version#: 1.15.4.993
Player Version#:

I’m seeing lots of reports of remote access problems, particularly after recent server updates. I think I’m in that club too.

I often use one my Echo Dots to listen to music from Plex library. One or two updates back (I think) Plex playback would occasionally stop between tracks - if I was to say “Alexa, ask Plex to continue”, playback would mostly restart but occasionally Alexa would report “Your Plex server does not appear to be online…”. That started happening more and more often.

Like others if I check the settings on my server I generally find it’s reporting that remote access if not available. When I clicked “retry” it would report that it was available again - I rather naively believed that. I did not realise this was either not the case or that remote access was failing again very soon afterwards.

Since the most recent server update (just a day or two ago) my Echo’s are unable to access my server at all. Again. like others, if I “retry” or reset the remote access settings it reports available but then pretty much immediately returns to unavailable.

I am currently using manual port forwarding - but I believe I always have done, without issue. canyouseeme.org reports my port (the standard 32400) is open.

I’ve read many of the posts reporting this issue now, on different platforms and using different kit, but I don’t think I’ve seen any real solution. Have I missed something?

I’m happy to provide any additional info if that would be useful.

Regards,

jarsudsco

2

I don’t want to hijack anyone else’s thread so I’m just adding this here for information. I clicked on the console link from my server’s management page - I noticed a fairly regular pattern of messages. I’m only including the relevant debug messages below as the remainder contain lots of information that I might not be wise to share…

May 02, 2019 19:20:01.214 [0x700008a89000] Debug — MyPlex: We appear to have regained Internet connectivity.
:
May 02, 2019 19:20:31.215 [0x700008a06000] Debug — MyPlex: We appear to have lost Internet connectivity, resetting device URL cache.
:
May 02, 2019 19:20:46.379 [0x700008a89000] Debug — MyPlex: We appear to have regained Internet connectivity.
:
May 02, 2019 19:21:16.385 [0x700008a89000] Debug — MyPlex: We appear to have lost Internet connectivity, resetting device URL cache.
:
May 02, 2019 19:21:31.569 [0x700008a89000] Debug — MyPlex: We appear to have regained Internet connectivity.
:
May 02, 2019 19:22:01.572 [0x700008a89000] Debug — MyPlex: We appear to have lost Internet connectivity, resetting device URL cache.
:
May 02, 2019 19:22:16.753 [0x700008a06000] Debug — MyPlex: We appear to have regained Internet connectivity.
:
May 02, 2019 19:22:46.756 [0x700008a06000] Debug — MyPlex: We appear to have lost Internet connectivity, resetting device URL cache.
:
May 02, 2019 19:23:02.036 [0x700008a06000] Debug — MyPlex: We appear to have regained Internet connectivity.
:
May 02, 2019 19:23:32.040 [0x700008a06000] Debug — MyPlex: We appear to have lost Internet connectivity, resetting device URL cache.
:
May 02, 2019 19:23:47.209 [0x700008a89000] Debug — MyPlex: We appear to have regained Internet connectivity.

It’s a fairly clear pattern - internet connectivity up for almost exactly 30 seconds, internet connectivity lost for almost exactly 15 seconds - repeat.

I’m no expert but I know enough to find it difficult to believe this is a problem with anything other than PMS - if it was my LAN, my router, my internet connection | would surely be seeing problems elsewhere too…?

Can’t we have a pinned topic in this forum updating everyone on what is clearly a serious and widespread problem?

3

I’m just gonna keep banging on about this here in the hope something proves useful…

Here is one complete “cycle” of connection regained-lost-regained console messages, I can’t see anything that is sensitive in this section, if I’m wrong I hope someone will let me know…

May 02, 2019 19:23:02.036 [0x700008a06000] Debug — MyPlex: We appear to have regained Internet connectivity.

May 02, 2019 19:23:07.820 [0x700008a89000] Debug — Completed: [127.0.0.1:51857] -2 GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (5 live) GZIP 20003ms 5 bytes (pipelined: 136)
May 02, 2019 19:23:07.828 [0x700008a89000] Debug — Auth: authenticated user 1 as Jarsudsco
May 02, 2019 19:23:07.828 [0x70000856b000] Debug — Request: [127.0.0.1:51857 (Loopback)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (5 live) GZIP Signed-in Token (Jarsudsco)
May 02, 2019 19:23:07.829 [0x70000856b000] Warning — [CompanionPlayer] We already have a handler, overwriting.
May 02, 2019 19:23:14.411 [0x700009130000] Debug — NetworkServiceBrowser: Parsing SSDP schema for http://192.168.0.112:49153/description0.xml
May 02, 2019 19:23:14.411 [0x700009130000] Debug — HTTP requesting GET http://192.168.0.112:49153/description0.xml
May 02, 2019 19:23:14.430 [0x700009130000] Debug — HTTP 401 response from GET http://192.168.0.112:49153/description0.xml
May 02, 2019 19:23:14.430 [0x700009130000] Error — SSDP: Error parsing device schema for http://192.168.0.112:49153/description0.xml
May 02, 2019 19:23:27.833 [0x700008a89000] Debug — Completed: [127.0.0.1:51857] -2 GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (5 live) GZIP 20004ms 5 bytes (pipelined: 137)
May 02, 2019 19:23:27.840 [0x700008a89000] Debug — Auth: authenticated user 1 as Jarsudsco
May 02, 2019 19:23:27.840 [0x7000085ee000] Debug — Request: [127.0.0.1:51857 (Loopback)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (5 live) GZIP Signed-in Token (Jarsudsco)
May 02, 2019 19:23:27.840 [0x7000085ee000] Warning — [CompanionPlayer] We already have a handler, overwriting.
May 02, 2019 19:23:32.039 [0x700008a06000] Error — getaddrinfo(192-168-0-30.abcdefghijklmnopqrstuvwxyz012345.plex.direct) failed: 8
May 02, 2019 19:23:32.039 [0x700008a06000] Debug — Network: 192-168-0-30.abcdefghijklmnopqrstuvwxyz012345.plex.direct failed to resolve to 192.168.0.30 but instead yielded “”
May 02, 2019 19:23:32.039 [0x700008a06000] Debug — PublicAddressManager: Obtaining public address and mapping port.
May 02, 2019 19:23:32.040 [0x700009548000] Debug — PublicAddressManager: Obtaining public IP.
May 02, 2019 19:23:32.040 [0x700008a06000] Debug — EventSource: Successfully connected to 109.237.24.233.
May 02, 2019 19:23:32.040 [0x700009548000] Debug — HTTP requesting GET http://plex.tv/pms/:/ip
May 02, 2019 19:23:32.040 [0x700008a06000] Debug — EventSource: Failure in IdleTimeout (0 - Undefined error: 0).

May 02, 2019 19:23:32.040 [0x700008a06000] Debug — MyPlex: We appear to have lost Internet connectivity, resetting device URL cache.

May 02, 2019 19:23:32.040 [0x700008a06000] Error — EventSource: Retrying in 15 seconds.
May 02, 2019 19:23:32.111 [0x700009548000] Debug — HTTP 200 response from GET http://plex.tv/pms/:/ip
May 02, 2019 19:23:32.111 [0x700009548000] Debug — PublicAddressManager: Got public IP from http://plex.tv: 86.142.203.141
May 02, 2019 19:23:35.131 [0x700009548000] Debug — NAT: UPnP, found device http://192.168.0.1:8000/jgtlbvhzgan/IGD/upnp/IGD.xml with private address <192.168.0.30>
May 02, 2019 19:23:35.167 [0x700009548000] Debug — NAT: UPnP, not connected or has no external IP: http://192.168.0.1:8000/jgtlbvhzgan/IGD/upnp/IGD.xml(urn:schemas-upnp-org:service:WANPPPConnection:1).
May 02, 2019 19:23:35.167 [0x700009548000] Debug — NAT: UPnP, no servicetype: http://192.168.0.1:8000/jgtlbvhzgan/IGD/upnp/IGD.xml(1).
May 02, 2019 19:23:35.167 [0x700009548000] Debug — NAT: UPnP, getPublicIP didn’t find usable IGD.
May 02, 2019 19:23:45.169 [0x700009548000] Warning — NAT: PMP, timed out waiting for response.
May 02, 2019 19:23:45.170 [0x700009548000] Debug — MyPlex: Updating device connections (from timer: 0)
May 02, 2019 19:23:45.170 [0x700009548000] Debug — HTTP requesting PUT https://plex.tv/devices/a3c359ac4cf5c17ec6f8448d921cfa116f52bf90?Connection[][uri]=http://192.168.0.30:32400&httpsEnabled=1&httpsRequired=0&dnsRebindingProtection=1&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
May 02, 2019 19:23:45.454 [0x700009548000] Debug — HTTP 200 response from PUT https://plex.tv/devices/a3c359ac4cf5c17ec6f8448d921cfa116f52bf90?Connection[][uri]=http://192.168.0.30:32400&httpsEnabled=1&httpsRequired=0&dnsRebindingProtection=1&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
May 02, 2019 19:23:45.930 [0x700009130000] Debug — NetworkServiceBrowser: Parsing SSDP schema for http://192.168.0.112:49153/description1.xml
May 02, 2019 19:23:45.931 [0x700009130000] Debug — HTTP requesting GET http://192.168.0.112:49153/description1.xml
May 02, 2019 19:23:45.949 [0x700009130000] Debug — HTTP 401 response from GET http://192.168.0.112:49153/description1.xml
May 02, 2019 19:23:45.950 [0x700009130000] Error — SSDP: Error parsing device schema for http://192.168.0.112:49153/description1.xml
May 02, 2019 19:23:47.045 [0x700008a89000] Debug — EventSource: Resolving 109.237.24.233 port 443
May 02, 2019 19:23:47.046 [0x700008a89000] Debug — EventSource: Resolved 109.237.24.233 to 109.237.24.233
May 02, 2019 19:23:47.107 [0x700008a06000] Debug — EventSource: Connected in 43 ms.
May 02, 2019 19:23:47.107 [0x700008a06000] Debug — EventSource: Wrote data, reading reply.
May 02, 2019 19:23:47.209 [0x700008a89000] Debug — EventSource: Read HTTP reply header.

May 02, 2019 19:23:47.209 [0x700008a89000] Debug — MyPlex: We appear to have regained Internet connectivity.

At least it’s now obvious to me where the 15 second delay is being generated… “EventSource: Retrying in 15 seconds.”

The next question I had was regarding IP address 109.237.24.233 - I didn’t think this was anything to do with me or any of my devices. Whois returns the following:

% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer: whois.ripe.net

inetnum: 109.0.0.0 - 109.255.255.255
organisation: RIPE NCC
status: ALLOCATED

whois: whois.ripe.net

changed: 2009-01
source: IANA

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the “-B” flag.

% Information related to ‘109.237.24.0 - 109.237.27.255’

% Abuse contact for ‘109.237.24.0 - 109.237.27.255’ is ‘abuse@linode.com’

inetnum: 109.237.24.0 - 109.237.27.255
netname: US-LINODE-20100108
country: GB
org: ORG-LL72-RIPE
admin-c: TA2589-RIPE
tech-c: TA2589-RIPE
status: ALLOCATED PA
remarks: Please send abuse reports to abuse@linode.com
remarks: This block is used for static customer allocations
mnt-by: RIPE-NCC-HM-MNT
mnt-by: linode-mnt
mnt-lower: Linode-mnt
mnt-domains: Linode-mnt
mnt-routes: Linode-mnt
created: 2015-03-31T15:12:17Z
last-modified: 2018-06-19T08:19:49Z
source: RIPE # Filtered

organisation: ORG-LL72-RIPE
org-name: Linode, LLC
org-type: LIR
address: 249 Arch Street
address: 19106
address: Philadelphia
address: UNITED STATES
phone: +16093807100
fax-no: +16093807200
admin-c: AF11785-RIPE
admin-c: TA2589-RIPE
tech-c: AF11785-RIPE
abuse-c: LAS85-RIPE
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: linode-mnt
mnt-by: RIPE-NCC-HM-MNT
mnt-by: linode-mnt
created: 2009-11-02T13:42:45Z
last-modified: 2018-06-19T01:10:36Z
source: RIPE # Filtered

person: Thomas Asaro
address: 329 E. Jimmie Leeds Road, Suite A, Galloway, NJ 08205, USA
phone: +16093807504
nic-hdl: TA2589-RIPE
mnt-by: Linode-mnt
created: 2009-11-02T17:17:56Z
last-modified: 2014-11-20T18:51:15Z
source: RIPE

% Information related to ‘109.237.24.0/22AS15830’

route: 109.237.24.0/22
descr: Linode-2
origin: AS15830
mnt-by: Linode-mnt
created: 2015-04-29T14:45:04Z
last-modified: 2015-04-29T14:45:04Z
source: RIPE

% This query was served by the RIPE Database Query Service version 1.93.2 (BLAARKOP)

And a traceroute to that address appears to fail - at least intermittently:

traceroute to 109.237.24.233 (109.237.24.233), 64 hops max, 52 byte packets
1 seraph.matrix.net (192.168.0.1) 1.269 ms 0.773 ms 0.985 ms
2 * * *
3 31.55.187.177 (31.55.187.177) 15.870 ms 15.685 ms 15.978 ms
4 31.55.187.176 (31.55.187.176) 16.425 ms 19.788 ms 16.833 ms
5 core1-hu0-6-0-8.southbank.ukcore.bt.net (213.121.192.76) 16.142 ms
core1-hu0-12-0-3.southbank.ukcore.bt.net (195.99.127.44) 16.302 ms
core3-te0-12-0-13.faraday.ukcore.bt.net (213.121.192.102) 31.678 ms
6 109.159.252.146 (109.159.252.146) 16.069 ms
peer6-hu0-6-0-6.telehouse.ukcore.bt.net (195.99.127.3) 17.219 ms
core4-hu0-2-0-4.faraday.ukcore.bt.net (195.99.127.70) 43.139 ms
7 t2c3-et-3-3-0-0.uk-lon1.eu.bt.net (166.49.211.238) 17.403 ms
t2c3-et-7-3-0-0.uk-lon1.eu.bt.net (166.49.211.230) 17.660 ms
213.137.183.102 (213.137.183.102) 31.607 ms
8 ae-11.r24.londen12.uk.bb.gin.ntt.net (195.66.224.138) 17.599 ms 17.196 ms 17.223 ms
9 ae-1.r05.londen12.uk.bb.gin.ntt.net (129.250.4.105) 23.217 ms 17.638 ms 25.607 ms
10 199.245.16.70 (199.245.16.70) 18.104 ms 18.790 ms
ldn-b4-link.telia.net (62.115.134.135) 39.168 ms
11 109.74.207.3 (109.74.207.3) 16.741 ms
109.74.207.23 (109.74.207.23) 22.756 ms
linode-ic-332557-ldn-b4.c.telia.net (62.115.41.65) 17.469 ms
12 * 109.74.207.27 (109.74.207.27) 18.612 ms
109.74.207.49 (109.74.207.49) 18.314 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * seraph.matrix.net (192.168.0.1) 1.255 ms !H 0.887 ms !H

I don’t know what to make of all of this, but my up-down-up connection appears to be related to accessing that particular IP address. Am I barking up the wrong tree?

4

So, I’ve been experiencing this same issue. I have Tautulli monitoring enabled and it does not tell me that “Remote Access” is lost and/or not available. This has been happening ever since I updated with the latest server-side update.

I don’t have network issues, but I happened to run a packet capture and I have verified it’s not a network issue.

5

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