I had the same exact issue plaguing my system for months. Spent countless hours trying different methods to get it to work. Disabling ipv6 resolved my issue as well. THANKS EVERYONE!!!
Same problem. Havenāt been able to get any metadata for new media for the past few days.
Same issueā¦
@sa2000 said:
@nperron said:
Iām assuming this bug will be corrected on the next update ? very annoyingIf ipv6 is causing timeouts on metadata requests for images, please disable it on the network card
Is this a joke? This is your solution?!?
@sa2000 said:
would like to establish why the availability of ipv6 ip addresses for image.tmdb.org is impacting some users but not others when ipv6 is in use on the networkWould like each person who has confirmed that it was ipv6 that was affecting metadata / images being fetched to let me know
- the location of the server (territory)
- what ISP is the connection through
Territory - USA
ISP - Comcast/Xfinity
disabling ipv6 on my network adapter worked for me too. very frustrating issue, just glad someone figured out a temporary fix.
Are we thinking this fix is on the 2018 or 2019 roadmap? Just curiousā¦
Had the same issue here, needed to disable ipv6 on the network adapter to get metadata working again. Ended up replacing my old router to allow for ipv6 internet access from my home network. Then re-enabled ipv6 support on the network adapter, and checked ipv6 support within Plex. Metadata working again.
Thank you! Iād been having issues with metadata loading for ages, and was unable to find a fix until now. I was looking through my agent logs and definitely noticed 100s delays in fetching resources; and disabling ipv6 on my ethernet adapter made everything work.
Although I did notice an odd twist - most of the poster / art resources and the XML metadata did in fact download (eventually), but didnāt make it into the database. You could go into Plex Media Server\Metadata\Movies\<ID>.bundle\Contents\ for any given movie, and .\com.plexapp.agents.imdb would have the Info.xml file with all the correct data in it, and \art and \posters would have a bunch of randomly named files that open successfully in an image editor. But .\_combined\Info.xml would have all its entries blank, and there would be no data in the app itself. I never got around to digging in the SQLite database, but Iād suspect the data wouldnāt be in there either.
So despite taking 100s per entry, it seems that some data was downloaded, but then the part that collects it to the database timed out as well? Hard to say, but thatās what I found.
For the IPV6 ISP network survey - RCN, in the Boston area. I didnāt think they even supported IPV6 on consumer connections yet, but maybe thatās new and when I began having issues?
@benbreton said:
Although I did notice an odd twist - most of the poster / art resources and the XML metadata did in fact download (eventually), but didnāt make it into the database. You could go intoPlex Media Server\Metadata\Movies\<ID>.bundle\Contents\for any given movie, and.\com.plexapp.agents.imdbwould have theInfo.xmlfile with all the correct data in it, and\artand\posterswould have a bunch of randomly named files that open successfully in an image editor. But.\_combined\Info.xmlwould have all its entries blank, and there would be no data in the app itself. I never got around to digging in the SQLite database, but Iād suspect the data wouldnāt be in there either.So despite taking 100s per entry, it seems that some data was downloaded, but then the part that collects it to the database timed out as well? Hard to say, but thatās what I found.
Yes - the requests were made and got queued and got sent but the threads making the requests would have timed out before the results came back
@sdownes said:
Looks like disabling IPv6 on the properties of my ethernet adaptor worked for me too! Thanks for all the help.
Hi
Could you do a specific test for us please?
- Download curl.exe from curl - Download
- Re-enable ipv6 temporarily within your router and ethernet adapter
- Run the following in a command line window
curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg - let me have the displayed curl command output - copy to text file and attach
- disable ipv6 as before
Thanks
My woes are similar. I have completely uninstalled and reinstalled PMS and disabled IPv6 (on my router, PMS, and network adapter) in an attempt to get the metadata to download correctly. After doing both of these, on the initial library scan I got movie metadata and (low-res) posters to download. Television metadata did not download but one (low-res) poster per show did (not individual season posters). I then added a movie and television show to see what would happen trying to update the library with new content. The added movie initially appeared to download a poster but after it did the flip the poster disappeared. The metadata did download for the movie. Refresh did not help the poster reappear. The added television show did download a (low-res) poster but still did not download any metadata.
Let me know if there is anything I can do to help get to the bottom of this.
Windows 10 Pro 64-bit
PMS Version 1.10.1.4602
@nyc_derek said:
My woes are similar. I have completely uninstalled and reinstalled PMS and disabled IPv6 (on my router, PMS, and network adapter) in an attempt to get the metadata to download correctly. After doing both of these, on the initial library scan I got movie metadata and (low-res) posters to download. Television metadata did not download but one (low-res) poster per show did (not individual season posters). I then added a movie and television show to see what would happen trying to update the library with new content. The added movie initially appeared to download a poster but after it did the flip the poster disappeared. The metadata did download for the movie. Refresh did not help the poster reappear. The added television show did download a (low-res) poster but still did not download any metadata.Let me know if there is anything I can do to help get to the bottom of this.
Windows 10 Pro 64-bit
PMS Version 1.10.1.4602
This forum thread is specifically relating to the issue caused by the timeouts on the ipv6 routes to image.tmdb.org
I would suggest you raise a separate forum topic including details of a test movie into a test library and with screenshots and debug logging when the problem arises
See https://support.plex.tv/articles/201643703-reporting-issues-with-plex-media-server/
https://support.plex.tv/articles/200250417-plex-media-server-log-files/
and for naming standards - try to adhere to tmdb and tvdb
https://support.plex.tv/articles/categories/media-preparation/
@sa2000 said:
@sdownes said:
Looks like disabling IPv6 on the properties of my ethernet adaptor worked for me too! Thanks for all the help.Hi
Could you do a specific test for us please?
- Download curl.exe from curl - Download
- Re-enable ipv6 temporarily within your router and ethernet adapter
- Run the following in a command line window
curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg- let me have the displayed curl command output - copy to text file and attach
- disable ipv6 as before
Thanks
*** First test, with IPv6 turned OFF in Ethernet adapter settings:
>curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:399b...
* TCP_NODELAY set
* Connected to image.tmdb.org (2400:cb00:2048:1::6810:399b) port 80 (#0)
> GET /t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg HTTP/1.1
> Host: image.tmdb.org
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 02 Feb 2018 22:21:07 GMT
< Content-Type: image/jpeg
< Content-Length: 9128
< Connection: keep-alive
< Set-Cookie: __cfduid=d8ed9e3588c579bc9ceae9d13c0ae592f1517610067; expires=Sat, 02-Feb-19 22:21:07 GMT; path=/; domain=.tmdb.org; HttpOnly
< Access-Control-Allow-Origin: *
< Cache-Control: max-age=31449600
< Cf-Bgj: imgq:85
< Cf-Polished: degrade=85, origSize=41441
< Etag: "40472f4fa461354f43f6569eca7abbd1"
< Expires: Tue, 11 Dec 2018 11:51:02 GMT
< Last-Modified: Sun, 08 Oct 2017 20:52:43 GMT
< X-Content-Digest: 3aff7a889e7fa025e98f2a56c67ef4cd6b71c191
< X-Rack-Cache: fresh
< CF-Cache-Status: HIT
< Accept-Ranges: bytes
< Server: cloudflare
< CF-RAY: 3e708aaa21525631-ORD
<
{ [527 bytes data]
* Connection #0 to host image.tmdb.org left intact
If IPv6 networking is turned off, I have no idea how itās connecting to an IPv6 address like that. But sure, weāll go with it.
I wonder if the Server: cloudflare part is relevant?
*** Next test, with IPv6 turned ON in Ethernet adapter settings:
>curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:3b9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3b9b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:3d9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3d9b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:399b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:399b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:3c9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3c9b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:3a9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3a9b port 80 failed: Timed out
* Failed to connect to image.tmdb.org port 80: Timed out
* Closing connection 0
Well, that does confirm what we expected.
*** Another test, using Bash and the Linux version of curl, via the Linux on Windows subsystem I happened to already have installed:
$ curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:3a9b...
* connect to 2400:cb00:2048:1::6810:3a9b port 80 failed: Connection refused
* Trying 2400:cb00:2048:1::6810:3b9b...
* connect to 2400:cb00:2048:1::6810:3b9b port 80 failed: Connection refused
* Trying 2400:cb00:2048:1::6810:3d9b...
* connect to 2400:cb00:2048:1::6810:3d9b port 80 failed: Connection refused
* Trying 2400:cb00:2048:1::6810:3c9b...
* connect to 2400:cb00:2048:1::6810:3c9b port 80 failed: Connection refused
* Trying 2400:cb00:2048:1::6810:399b...
* connect to 2400:cb00:2048:1::6810:399b port 80 failed: Connection refused
* Failed to connect to image.tmdb.org port 80: Connection refused
* Closing connection 0
Interesting that it says Connection refused instead of just timed out. They both took the exact same amount of time per attempt though.
*** Bonus test, using my MacOS laptop on the same network, over WiFi. I honestly donāt know if IPv6 is even configured on this connection, but I figured Iād give it a try.
$ curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:3b9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3b9b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3d9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3d9b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:399b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:399b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3c9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3c9b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3a9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3a9b port 80 failed: Network is unreachable
* Failed to connect to image.tmdb.org port 80: Network is unreachable
* Closing connection 0
There arenāt any timestamps here, but while the other tests all took several seconds to time out (although less than a minute) per attempt, this one was only 1-2 seconds to error out.
Thank you @benbreton
@benbreton said:
*** First test, with IPv6 turned OFF in Ethernet adapter settings:If IPv6 networking is turned off, I have no idea how itās connecting to an IPv6 address like that. But sure, weāll go with it.
I wonder if the
Server: cloudflarepart is relevant?*** Next test, with IPv6 turned ON in Ethernet adapter settings:
Well, that does confirm what we expected.
Have been discussing the test results with our operations team - concentrating on your tests 1 and 2
What it looks like is as if the enable / disable ipv6 is the wrong way round for some reason
In the first test when you disabled it, we successfully reached the image.tmdb.org through an ipv6 address
In the second test when you enabled ipv6, it could not reach the image.tmdb.org through any of the ipv6 addresses
Very strange
Wonder if the same outcome is from others ? and if it is the same for other operating systems
@benbreton said:
*** First test, with IPv6 turned OFF in Ethernet adapter settings:If IPv6 networking is turned off, I have no idea how itās connecting to an IPv6 address like that. But sure, weāll go with it.
I wonder if the
Server: cloudflarepart is relevant?*** Next test, with IPv6 turned ON in Ethernet adapter settings:
Well, that does confirm what we expected.
Have been discussing the test results with our operations team - concentrating on your tests 1 and 2
What it looks like is as if the enable / disable ipv6 is the wrong way round for some reason
In the first test when you disabled it, we successfully reached the image.tmdb.org through an ipv6 address
In the second test when you enabled ipv6, it could not reach the image.tmdb.org through any of the ipv6 addresses
Very strange
Wonder if the same outcome is from others ? and if it is the same for other operating systems
@sa2000 said:
@benbreton said:
*** First test, with IPv6 turned OFF in Ethernet adapter settings:If IPv6 networking is turned off, I have no idea how itās connecting to an IPv6 address like that. But sure, weāll go with it.
I wonder if the
Server: cloudflarepart is relevant?*** Next test, with IPv6 turned ON in Ethernet adapter settings:
Well, that does confirm what we expected.
Have been discussing the test results with our operations team - concentrating on your tests 1 and 2
What it looks like is as if the enable / disable ipv6 is the wrong way round for some reason
In the first test when you disabled it, we successfully reached the image.tmdb.org through an ipv6 address
In the second test when you enabled ipv6, it could not reach the image.tmdb.org through any of the ipv6 addressesVery strange
Wonder if the same outcome is from others ? and if it is the same for other operating systems
Could you do some ipv6 tests with google as with ipv6 enabled and disabled
Suggest testing
curl -ksv6 "https://ipv6test.google.com/" > test.html
Iāll test the Windows box thatās running Plex in a little bit when I get a chance, but real quick since Iām on my Macbook:
$ curl -ksv6o test.html https://ipv6test.google.com/
* Trying ::ffff:172.217.12.132...
* TCP_NODELAY set
* Connected to ipv6test.google.com (::ffff:172.217.12.132) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [96 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3908 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com
* start date: Jan 16 08:54:09 2018 GMT
* expire date: Apr 10 08:42:00 2018 GMT
* issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff76b800400)
> GET / HTTP/2
> Host: ipv6test.google.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< accept-ranges: none
< vary: Accept-Encoding
< content-type: text/html
< date: Sun, 04 Feb 2018 15:47:28 GMT
< expires: Sun, 04 Feb 2018 15:47:28 GMT
< cache-control: private, max-age=0
< last-modified: Mon, 21 Aug 2017 23:45:00 GMT
< x-content-type-options: nosniff
< server: sffe
< x-xss-protection: 1; mode=block
< alt-svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
<
{ [1380 bytes data]
* Connection #0 to host ipv6test.google.com left intact
While the TMDB server is still the same:
$ curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:399b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:399b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3a9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3a9b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3c9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3c9b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3b9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3b9b port 80 failed: Network is unreachable
* Trying 2400:cb00:2048:1::6810:3d9b...
* TCP_NODELAY set
* Connection failed
* connect to 2400:cb00:2048:1::6810:3d9b port 80 failed: Network is unreachable
* Failed to connect to image.tmdb.org port 80: Network is unreachable
* Closing connection 0
Note however that Google is using an IPv4-mapped IPv6 address:
::ffff:172.217.12.132 - see The TCP/IP Guide - IPv6/IPv4 Address Embedding
Regular full IPv6 addresses fail, which gives us this interesting pair:
curl -sv6o test.html http://ipv6-test.com/
* Trying 2001:41d0:8:e8ad::1...
* TCP_NODELAY set
* Connection failed
* connect to 2001:41d0:8:e8ad::1 port 80 failed: Network is unreachable
* Failed to connect to ipv6-test.com port 80: Network is unreachable
* Closing connection 0
and
curl -sv6o test.html http://test-ipv6.com/
* Trying ::ffff:216.218.228.125...
* TCP_NODELAY set
* Connected to test-ipv6.com (::ffff:216.218.228.125) port 80 (#0)
> GET / HTTP/1.1
> Host: test-ipv6.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 04 Feb 2018 15:54:12 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Content-Location: index.html.en_US
< Vary: negotiate,accept-language,accept-encoding
< TCN: choice
< Last-Modified: Fri, 02 Feb 2018 15:36:49 GMT
< ETag: "5643c7b1188ec"
< Accept-Ranges: bytes
< Content-Length: 30974
< Content-Type: text/html; charset=utf-8
< Content-Language: en-us
<
{ [11219 bytes data]
* Connection #0 to host test-ipv6.com left intact
So it definitely depends on if the server is set for compatibility.
I also double checked, and the Mac and my router both support IPv6 fine, and even have local addresses set, but itās not enabled on my ISP side.
Exhibit A, Router config:
Exhibit B, test-ipv6.com:
Like I said, Iāll check under Windows when I get a chance, but my best guess right now is just that when IPv6 is disabled in the adapter, curl is silently falling back to looking up the IPv4 address. Iāll have to test feeding it an address directly instead of a hostname.
Oh, and one other thing that might be relevant - I have my DNS set to use Googleās 8.8.8.8 DNS server, not my ISPās by default. That might be allowing for the lookups succeedingā¦
could you edit your post and add note for each test to say if ipv6 was enabled or disabled on the network card
Could the issue be - network cards having ipv6 enabled but ISP has not enabled ipv6 for you - and complimented by the image.tmdb.org not supporting IPv4-mapped IPv6 addresses ?
As I mentioned, those tests were done from my Macbook, so IPv6 was enabled the whole time.
Hereās my Windows results:
IPv6 OFF on network card:
> curl -ksv6o test.html https://ipv6test.google.com/
* Could not resolve host: ipv6test.google.com
* Closing connection 0
> curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:3a9b...
* TCP_NODELAY set
* Connected to image.tmdb.org (2400:cb00:2048:1::6810:3a9b) port 80 (#0)
> GET /t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg HTTP/1.1
> Host: image.tmdb.org
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
> curl -sv6o test.html http://ipv6-test.com/
* Trying 2001:41d0:8:e8ad::1...
* TCP_NODELAY set
* Connected to ipv6-test.com (2001:41d0:8:e8ad::1) port 80 (#0)
> GET / HTTP/1.1
> Host: ipv6-test.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
> curl -sv6o test.html http://test-ipv6.com/
* Could not resolve host: test-ipv6.com
* Closing connection 0
So far, it does kinda look like itās failing on the domains with the IPv4-mapped IPv6 addresses. Maybe the reverse-setting theory has some meritā¦
> curl -svo test.html http://test-ipv6.com/
* Trying 96.119.179.228...
* TCP_NODELAY set
* Connected to test-ipv6.com (96.119.179.228) port 80 (#0)
> GET / HTTP/1.1
> Host: test-ipv6.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
> curl -svo test.html 96.119.179.228
* Rebuilt URL to: 96.119.179.228/
* Trying 96.119.179.228...
* TCP_NODELAY set
* Connected to 96.119.179.228 (96.119.179.228) port 80 (#0)
> GET / HTTP/1.1
> Host: 96.119.179.228
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
> curl -sv6o test.html 96.119.179.228
* Rebuilt URL to: 96.119.179.228/
* Trying 96.119.179.228...
* TCP_NODELAY set
* Connected to 96.119.179.228 (96.119.179.228) port 80 (#0)
> GET / HTTP/1.1
> Host: 96.119.179.228
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
Iām also wondering about what curl is actually doing behind the scenes. Itās perfectly happy to connect to an IPv4 address whether you give it the -6 flag or not.
Now for the web test at http://test-ipv6.com:
Oh. Ooohhhh. Now thatās interesting. Apparently turning off native IPv6 supportā¦ enables tunneling instead? I think weāre getting somewhere here.
Letās turn the IPv6 adapter support back ON and see what happens:
Yep. with native support on, it acts like itās supposed to, and as it did on the other computer - which in the case of my ISP, means failing the tests. So the moral of this story is, Windows has Teredo tunneling built in which it uses when IPv6 support is off.
> curl -ksv6o test.html https://ipv6test.google.com/
* Could not resolve host: ipv6test.google.com
* Closing connection 0
> curl -sv6o junk.jpg http://image.tmdb.org/t/p/w300/g8wnyyR6vlZjfdePD2v1lKGLUix.jpg
* Trying 2400:cb00:2048:1::6810:3a9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3a9b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:3c9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3c9b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:399b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:399b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:3b9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3b9b port 80 failed: Timed out
* Trying 2400:cb00:2048:1::6810:3d9b...
* TCP_NODELAY set
* connect to 2400:cb00:2048:1::6810:3d9b port 80 failed: Timed out
* Failed to connect to image.tmdb.org port 80: Timed out
* Closing connection 0
> curl -sv6o test.html http://ipv6-test.com/
* Trying 2001:41d0:8:e8ad::1...
* TCP_NODELAY set
* connect to 2001:41d0:8:e8ad::1 port 80 failed: Timed out
* Failed to connect to ipv6-test.com port 80: Timed out
* Closing connection 0
> curl -sv6o test.html http://test-ipv6.com/
* Could not resolve host: test-ipv6.com
* Closing connection 0
Sooooā¦ the IPv6-only sites find an address, but canāt connect to it. The IPv4-mapped IPv6 sites have unresolvable hostnames.
Letās try giving it the IPv6 address for https://ipv6test.google.com directly:
> curl -sv6o test.html http://[::ffff:172.217.12.132]
* Rebuilt URL to: http://[::ffff:172.217.12.132]/
* Trying ::ffff:172.217.12.132...
* TCP_NODELAY set
* connect to ::ffff:172.217.12.132 port 80 failed: Address not available
* Failed to connect to ::ffff:172.217.12.132 port 80: Address not available
* Closing connection 0
Ok, fair enough.
Well, thatās all the tests I can think of. Found a couple interesting results, now itās up to a better network engineer than I to figure out what to do about it 
