We have been happily using JWPlayer for years, but lately we've been having quite a lot of complaints from users (staff and students) that often the player initialization takes more than 30 secs thus failing. We've been troubleshooting it and the reason seems to be that sometimes IPv6 requests from ssl.p.jwpcdn.com timeout when loading javascripts - it can take up to two minutes to get the file. IPv4 is working just fine. Anyone else having the same problem? The local network admins here suspected a cdn-related problem.
I tried this from different operators and it seems that the service is down at the same time for all (at one moment it works, on another it just hangs). Example dump of test below (the problem seems to be the same with no relation if I try the newest or some older include files):
Just heard back. Are you still having the problem? I see that the same request 15 min later was successful. We are not hearing about this from any other customers, so the problem may have been on your side.
Yeah, It's still a current issue, and seems to keep happening daily for a short duration at a time on IPv6 (most of the time it works, but sometimes it just hangs for a while). I've managed to confirm the problem also outside our university's network so it shouldn't be related just to our network as, for example, just a moment ago the ssl.p.jwpcdn.com was not answering on IPv6 for a while from both our university's network as well as from a private company's network using a different network operator. Maybe it could be a problem on the CDN node closest to Helsinki, Finland? Or some other network peering issue on IPv6.
The network engineer in our office said that your issue may be due to routing issues.
We have two ISPs here in our office and only one of them works enough such that I can contact www.google.com. The other one claims that “Google has not chosen to peer with us via IPv6” and thus they can’t do anything about it. So while we say it works 100%, we cannot control routing on the internet. He also suggested that you speak with your ISP.
Additionally, can you please provide the output of traceroute / tracert / mtr? He said a wget is not very useful to diagnose network routing.
Hi, I did traceroute already back when I tested the issue from multiple networks to see that the other company I tried utilized another network provider all the way to FICIX to make sure it wasn't an operator related problem as different tests used different routes.
Our network admins said that "For the unsuccessful requests the remote site answers immediate 0 byte TPC ACK, then idles for about a minute after which a reply is received to the original TCP packet which included the GET request. [It] looks like a CDN issue."
I'll check with our network provider if they might see any additional hints about this.
Saving to: ‘/dev/null’
100%======================>] 2,140 —.-K/s in 0s
2017-08-08 23:26:56 (240 MB/s) – ‘/dev/null’ saved [2140/2140]
Would you be able to check again to see if you are getting the same issue?
Also, please use the -S and -O flags on your requests so that we can see which Edge server that request is hitting.
Hi, I raised the issue to our ISP who also said that it looks like a CDN issue.
Today I tested it for 5-10 minutes before it started hickuping again (it just idles at the 'awaiting response'). Here are the details for the edge server (apparently in Helsinki) which might be the problematic one.
