Plex media server 1.23.0.4438 unable to access server content (could not resolve host plex.tv)

Plex Media Server
1

RESOLVED IN LATEST STABLE VERSION 1.23.1.4602

Server Version#: 1.23.0.4438 (previously 1.22.2.4282)
Player Version#: N/A

After updating to v1.23.0.4438 I’m getting the resolving errors as shown below when accessing my server on all my devices. Just did a rollback to 1.22.2.4282 and all OK again right away.

  • When accessing the server via. e.g. web browser, “plex you do not have access to this server” is shown and server/settings unavailable via web- and/or Plex Media Player.
  • On the Android app, content navigation is accessible (after a few retries) but very slow and the same errors in the logs as shown below. Playback on Android after 2-3 tries.
  • Says plex.tv can not be resolved, but OS actually can and is reachable.
  • I’m using a reverse proxy (Nginx) to route my custom domain media.mydomain.xx. Never had any issues with this on previous version but might be worth noting.
Apr 28, 2021 00:01:13.308 [0x7f1036c97b38] WARN - HTTP error requesting GET https://plex.tv/media/providers?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (6, Couldn't resolve host name) (Could not resolve host: plex.tv)
Apr 28, 2021 00:01:13.308 [0x7f1036c97b38] ERROR - Error parsing content.
Apr 28, 2021 00:01:13.308 [0x7f1036c97b38] ERROR - Error parsing XML: Error parsing file.
Apr 28, 2021 00:01:18.622 [0x7f10385fbb38] ERROR - getaddrinfo(192-168-1-10.abcdefghijklmnopqrstuvwxyz012345.plex.direct) failed: -3
Apr 28, 2021 00:01:18.622 [0x7f10385fbb38] WARN - MyPlex: attempted a reachability check but we're not yet mapped.
Apr 28, 2021 00:01:18.622 [0x7f10385fbb38] ERROR - EventSource: Retrying in 15 seconds.
Apr 28, 2021 00:01:23.628 [0x7f103887fb38] ERROR - Error issuing curl_easy_perform(handle): 6
Apr 28, 2021 00:01:23.628 [0x7f103887fb38] WARN - HTTP error requesting GET http://plex.tv/pms/:/ip (6, Couldn't resolve host name) (Could not resolve host: plex.tv)
Apr 28, 2021 00:01:23.628 [0x7f103887fb38] ERROR - PublicAddressManager: Unable to get public IP adddress from myPlex (httpCode=-6):
Apr 28, 2021 00:01:28.285 [0x7f1038a13b38] ERROR - Error issuing curl_easy_perform(handle): 6
Apr 28, 2021 00:01:28.286 [0x7f1038a13b38] WARN - HTTP error requesting PUT https://plex.tv/devices/device_id?Connection[][uri]=https://media.mydomain.xx:48456&Connection[][uri]=http://192.168.1.10:32400&httpsEnabled=1&httpsRequired=1&dnsRebindingProtection=1&natLoopbackSupported=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (6, Couldn't resolve host name) (Could not resolve host: plex.tv)
Apr 28, 2021 00:01:28.286 [0x7f1038a13b38] WARN - MyPlex: Updating device connections failed, retrying in 80 seconds.
Apr 28, 2021 00:01:33.292 [0x7f103887fb38] ERROR - Error issuing curl_easy_perform(handle): 6
Apr 28, 2021 00:01:33.292 [0x7f103887fb38] WARN - HTTP error requesting PUT https://plex.tv/devices/device_id?Connection[][uri]=https://media.mydomain.xx:48456&Connection[][uri]=http://192.168.1.10:32400&httpsEnabled=1&httpsRequired=1&dnsRebindingProtection=1&natLoopbackSupported=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (6, Couldn't resolve host name) (Could not resolve host: plex.tv)
Apr 28, 2021 00:01:33.292 [0x7f103887fb38] WARN - MyPlex: Updating device connections failed, retrying in 10 seconds.
2

You need to turn DEBUG logging back on (which is ON by default) so we can see what’s happening.

Stop Plex
Add logDebug="1" to Preferences.xml
Start Plex

Now generate a usable set of logs

3

Hi Chuck,

Will try the update again later today, for some reason debug logging turns off automatically on my side after a while (~1 day generally). Is this known behavior?

“Plex Media Server.log” logging only enough or do you need any other log files?

4

Reinstalling seemed to work but it was using cached auth. After clearing the cache, same issue.

Created a fresh log after restart and accessing Plex via the web.

<edit: I see you are not accepting PMs, where can I share the log file? Not sure how much private information these logs expose so rather not publish them publicly>

Sent the log via PM. Thanks and let me know if you need any additional information.

5

Check you DM

6

Exact same problem here. Not using a reverse proxy.

What was the fix?

7

@Overlord_Malcolm

If you re-read, We’re not at that point YET.

8

Copy to continue here so others can follow - response on logfile from DM.

9

Than the question remains, what changed that this new version that causes this behavior now? If I curl directly there is no issue, nor is there any issue on the previous version (which I assume authenticates in a similar place).

Is by any chance IPv6 used by default is this new version for the curl call instead of IPv4? If that’s the case, than it’s explainable on my end.

curl plex.tv -v -4 (OK)
curl plex.tv -v -6 (Could not resolve - same error)
10

Do you have IPv4 and IPv6 enabled on the host?

If the ISP favors v6 (seems like it),
And you have dual stack,
It will be sent v6.

Plex.tv is still IPv4

I THOUGHT it has IPv6 somewhere…

Seems it’s only IPv4

11

Same thing here.

I am running the official Docker image, using plexpass tag and I am running into this issue.

Logs full of “Could not resolve host: plex.tv”. However curl the address from within the container works fine (defaults to IPv4).

Older versions work fine (Version 1.22.3.4392).

Yes I have dual stack IPv4/6, but this was working previously.

  • What has changed since Version 1.22.3.4392 (the version that runs fine, if I use latest tag image) that would prevent DNS from working?

  • Or that defaults to using IPv6 (if available)?

  • Can we get plex.tv listening on IPv6 (and some AAAA records?)

12

Folks,
Please hear what I’m saying by not saying?

There never has been V6 support at Plex.tv.

ISPs are starting to drop V4 support and it’s catching some by surprise.

“Message relayed & received”

13

I hear you - but are you hearing us? :slight_smile:

Same hardware host, with same host OS / network.
1 plexinc/pms-docker image works fine - no issues resolving plex.tv
The other cannot resolve the same address.

Both use the same docker-compose.yml, so same ENV variables, network - even same IP and MAC address.

There is a difference somewhere in the newer version that is trying to access plex.tv via IPv6 - when it should be using IPv4. The old image, even though it has the same IPv4 and IPv6 support (IPs, routes etc) correctly uses IPv4.

I am not changing anything on my system apart from which pms-docker image I am using - both are official.

If I use plexinc/pms-docker:plexpass - it downloads 1.23.0.4438 which doesn’t work.
If I use plexinc/pms-docker:latest - it runs 1.22.3.4392 which works.

Edit: Now plexpass is downloading 1.23.0.4497-a1b1f3c10, which also isn’t working.

I get similar errors for any/all requests to plex.tv under this version. However if I exec into the container and run a curl to plex.tv - it works fine.

Maybe this isn’t an IPv6 issue and we jumped to that conclusion? Maybe its a straight resolver issue in the code?

14

I hear you loud and clear. I just burned it all down and here we go…

[root@lizum chuck]# docker/dockerplex
Error response from daemon: No such container: plex
Error: No such container: plex
Unable to find image 'plexinc/pms-docker:plexpass' locally
plexpass: Pulling from plexinc/pms-docker
a70d879fa598: Pull complete 
c4394a92d1f8: Pull complete 
10e6159c56c0: Pull complete 
d1042fe57e96: Pull complete 
ac5317c7b384: Pull complete 
47414e89d67b: Pull complete 
Digest: sha256:8aeb4a982ea564ad309861dd251cd9e218aac3f4e4d3da21375568341be1b16f
Status: Downloaded newer image for plexinc/pms-docker:plexpass
054b972ca0533430a41ac56c84205401d698a91e14a049b69098bbd11beb41e8
plex
plex
[root@lizum chuck]# date
Fri May  7 12:55:30 AM EDT 2021
[root@lizum chuck]#  curl http://127.0.0.1:32400/identity
<?xml version="1.0" encoding="UTF-8"?>
<MediaContainer size="0" claimed="1" machineIdentifier="60f71869b66e0926daecc1b1048e56a0e278a62c" version="1.23.0.4497-a1b1f3c10">
</MediaContainer>
[root@lizum chuck]#

Screenshot from 2021-05-07 01-05-09
Screenshot from 2021-05-07 01-05-091238×404 230 KB

Screenshot from 2021-05-07 01-04-36
Screenshot from 2021-05-07 01-04-361032×485 181 KB

Screenshot from 2021-05-07 01-06-41
Screenshot from 2021-05-07 01-06-411365×388 115 KB

May 07, 2021 05:00:14.240 [0x7eff0bf12b38] DEBUG - Request: [127.0.0.1:46586 (Loopback)] GET / (4 live) GZIP Signed-in
May 07, 2021 05:00:14.240 [0x7eff0beefb38] DEBUG - Completed: [127.0.0.1:46588] 401 GET /media/providers (4 live) GZIP 0ms 357 bytes
May 07, 2021 05:00:14.240 [0x7eff0bf12b38] DEBUG - Completed: [127.0.0.1:46586] 401 GET / (3 live) GZIP 0ms 435 bytes
May 07, 2021 05:00:14.260 [0x7eff0b2f1b38] DEBUG - Request: [127.0.0.1:46584 (Loopback)] GET /identity (2 live) GZIP Signed-in
May 07, 2021 05:00:14.260 [0x7eff0beefb38] DEBUG - Completed: [127.0.0.1:46584] 200 GET /identity (2 live) GZIP 0ms 479 bytes (pipelined: 4)
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 172.104.218.101 was 66 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 45.79.128.184 was 66 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 45.79.211.188 was 77 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 172.105.99.32 was 82 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 45.33.119.35 was 121 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 184.105.148.114 was 166 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 178.79.180.168 was 206 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 82.94.168.18 was 216 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 172.104.245.130 was 241 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 139.162.120.52 was 392 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Time to connect to 139.162.40.38 was 544 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - PubSubManager: Updating best ping time for 172.104.218.101 to 66 ms.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - EventSource: Stopping.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - EventSource: Stopping.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - EventSource: Stopping.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - EventSource: Stopping.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - EventSource: Stopping.
May 07, 2021 05:00:14.407 [0x7eff0b0c0b38] DEBUG - EventSource: Stopping.

What am I not seeing?

Do I need break this out into its own thread ? It seems so?

15

Perhaps it might be for the best?
Thanks for taking the time to do that test above - was that just with IPv4 or dual stack?

I am modifying my own Docker config to be single IPv4 stack now, as a test.

Edit: Okay - just running the latest plexpass (beta update channel) without IPv6 enabled for Docker and the problem still exists. Very very odd!!!

Even worse - I have completely disabled IPv6 on my network, my server and the Docker network. Rebooted the network and my server.
The latest image STILL fails to connect to plex.tv?!

Using image plexinc/pms-docker:public used version 1.22.3.4392-d7c624def and works perfectly.
I still don’t get what is going on…

Next step is to install plex onto a brand new AWS EC2 instance and test there.

17

On the new PMS version, curl, for whatever reason, is trying to find the DNS server in the Global DNS configuration. The systemd resolved service marks the server currently in use with “Current DNS Server” (see below), which is correctly set but it still complained about having no DNS server available.

# resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
Fallback DNS Servers: 1.1.1.1 9.9.9.10 8.8.8.8 2606:4700:4700::1111 2620:fe::10 2001:4860:4860::8888

Link 3 (enp0s25)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 208.67.222.222

Using Curl just directly on my system still worked just fine and used the proper DNS, unsure as to why on the new version of Plex, curl fails.

# curl plex.tv
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

However dig did not work, which triggered me (i.e. dig had no DNS available).

# dig plex.tv

; <<>> DiG 9.16.15 <<>> plex.tv
;; global options: +cmd
;; connection timed out; no servers could be reached

After adding a DNS nameserver to my resolv config, it worked. Still unclear why this is necessary and I don’t like this “fix” as this shouldn’t be necessary.

I still would like to know what the new version of PMS does different, that might trigger this.

# dig plex.tv

; <<>> DiG 9.16.15 <<>> plex.tv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52122
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;plex.tv.                       IN      A

;; ANSWER SECTION:
plex.tv.                33      IN      A       108.128.10.254
plex.tv.                33      IN      A       99.81.164.127
plex.tv.                33      IN      A       99.81.153.144

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 07 12:55:50 CEST 2021
;; MSG SIZE  rcvd: 84
18

Extra note, seems like this has something to do with how glibc resolves, used by curl. Anyhow, adding nameserver entries to my resolv config “resolved” this.

19

There were changes to the build toolchain for 1.23. I wonder if there’s a different resolver lib or compile-time option that’s affecting resolver behavior?

DNS on “modern” Linux feels so complicated compared to the old days. Powerful, but so complicated.

20

I’ve chatted with the build team.

They have asked me to collect as much information as possible and present to them.

My thoughts on doing this were:

  1. Create the two different containers , showing docker file
  2. Shell into each
  3. Repeat the same commands in each which demonstrate the differences.
  4. Capture the shell output
  5. Place in respective files
  6. Forward to engineering.

Does anyone have anything else to add to this which will help demonstrate the issue(s) ?

21

I guess that’s all we can do. I have attached a tar.gz containing the docker-compose.yml file I used for each the “good” and “bad” plex instances. As you will see, they are exactly the same apart from the image used - same libraries etc.

Inside is also the “Plex Media Server.log” file from each.

Curl to https://plex.tv works fine from inside BOTH containers, so that indicates (to me) a problem in code rather than the container/OS itself.

TBH I doubt anyone will figure anything out from what I have attached. My containers all run on a MACVLAN Docker network, which really isn’t your standard setup.

But - I have been running with this setup for years and I have 32 containers currently running there, with no other issues. Something must have changed in this 1.23.0 build to be causing this grief.

Thanks for your help!

bad_plex.tar.gz (70.2 KB) good_plex.tar.gz (818.3 KB)