FlightAware Discussions

Something wrong with bundled IFR procedures?

When I download PDFs of individual procedures for an airport, it works fine, but when I try to download the bundled version that has all procedures in one file, it takes a huge amount of time to download (half an hour or so), and then Acrobat says the file is corrupt when I try to open it. What’s wrong?

Which airport?

I tried KLAX and KPHX, two airports that I “visit” frequently in simulation.

The downloads of the bundled PDFs have been very slow for a long time, but this is the worst it’s been, and this is the first time that I get a message in Acrobat telling me that the PDF is corrupt.

Maybe there’s something wrong with your browser or connection? I’m using Firefox version 19.0.2. It has built-in PDF viewing. I downloaded both PHX and LAX with no problems. Both downloaded in under a minute.

I’m using the same version of the same browser, and plates download just fine, except for the bundled ones. I note that the PDFs are being served from fr.flightaware.com. Maybe they are coming from a different server that has a problem. Even so, only the bundled PDF has the problem, not the other ones.

I’ll try the same thing from the office. If there is no problem, it’s my computer. If it’s the same problem, it’s the site. I’ll report the results here.

I’ve just tried this from the office. Same problem.

Running windows Vista SP2, Firefox 19.0.2:
Clicked on " All KLAX Procedures (with diagram)"
downloaded in about 5 min. Clicked file/ save page as/ download took a couple minutes. Adobe reader choked and said that the file was corrupted or (???) . Noted file size was 25 KB- a bit less than expected.

I then did a right click on " All KLAX Procedures (with diagram)" and selected “save link as”.
File downloaded at speed appropriate for my DSL connection. When finished filesize was 28,235 KB and opened correctly.
This may provide a clue to the problem and possible work around using ’ save as’.
Hope it helps.
"The Computer is NOT your friend

It could be a problem with the connection. There may be just enough “hiccups” in the connection to cause the files to be corrupted. I’m using cable which has a fairly fast download speed.

There is no problem with the connection. It should be a 30-second download. Obviously something is broken.

Here’s a traceroute to the host(s) that is apparently serving this content for IPs in France:

webmaster % traceroute
traceroute to (, 64 hops max, 40 byte packets
1 netgear ( 0.827 ms 0.677 ms 0.654 ms
2 net1lo-bidon.bsami551.Amiens.francetelecom.net ( 32.082 ms 32.353 ms 31.777 ms
3 ( 31.811 ms 30.850 ms 31.766 ms
4 ae43-0.nista301.Paris.francetelecom.net ( 33.028 ms 32.169 ms 30.974 ms
5 ( 52.028 ms 48.105 ms 47.286 ms
6 xe-0-0-0-6.r02.londen03.uk.bb.gin.ntt.net ( 40.190 ms 40.496 ms 40.932 ms
7 ( 40.376 ms 40.395 ms 39.128 ms
8 89-151-95-130.servers.dedipower.net ( 41.204 ms 41.493 ms 41.094 ms
9 89-151-95-142.servers.dedipower.net ( 40.664 ms
89-151-95-154.servers.dedipower.net ( 73.047 ms
89-151-95-150.servers.dedipower.net ( 41.510 ms
10 unallocated-85-151-84-232.red.flightaware.com ( 41.527 ms 40.434 ms 41.844 ms

And here’s a traceroute to the host(s) that serve the content for the U.S. (presumably):

webmaster % traceroute
traceroute to (, 64 hops max, 40 byte packets
1 netgear ( 0.789 ms 0.655 ms 0.636 ms
2 net1lo-bidon.bsami551.Amiens.francetelecom.net ( 32.840 ms 31.485 ms 31.512 ms
3 ( 32.011 ms 31.361 ms 31.771 ms
4 ae43-0.nista301.Paris.francetelecom.net ( 32.005 ms 31.281 ms 31.980 ms
5 ( 46.081 ms 46.895 ms 48.281 ms
6 xe-0-0-0-6.r02.londen03.uk.bb.gin.ntt.net ( 40.144 ms 39.679 ms 38.917 ms
7 ae-4.r22.londen03.uk.bb.gin.ntt.net ( 39.255 ms 39.731 ms 40.138 ms
8 as-0.r22.nycmny01.us.bb.gin.ntt.net ( 109.938 ms 117.939 ms 109.107 ms
9 ae-0.r23.nycmny01.us.bb.gin.ntt.net ( 131.867 ms 107.324 ms 109.122 ms
10 ae-1.r20.asbnva02.us.bb.gin.ntt.net ( 112.831 ms 113.619 ms 116.278 ms
11 ae-3.r20.dllstx09.us.bb.gin.ntt.net ( 153.003 ms 175.264 ms 145.560 ms
12 ae-2.r07.dllstx09.us.bb.gin.ntt.net ( 147.132 ms 154.358 ms 146.543 ms
13 xe-0-4-0-1.r07.dllstx09.us.ce.gin.ntt.net ( 154.772 ms 167.880 ms 165.798 ms
14 border1.ge4-1-bbnet2.ext1a.dal.pnap.net ( 158.238 ms 158.714 ms 154.912 ms
15 core5.te4-3.hou-dalext1a-1609.hou.pnap.net ( 165.416 ms 156.725 ms 194.864 ms
16 border10.ge6-2-bbnet2.hou.pnap.net ( 270.308 ms
border10.ge5-2-bbnet1.hou.pnap.net ( 227.917 ms
border10.ge6-2-bbnet2.hou.pnap.net ( 334.314 ms
17 * * *

My guess is that the first server farm has a problem, but the second does not, and probably connections to the first have never been tested, since testing is difficult to do from the U.S.

I’ve pulled Netmon out of the closet to take a look.

The request goes to, which responds with a 302, Moved temporarily. The redirected request is then sent to, an address that resolves to unallocated-85-151-84-232.red.flightaware.com, which is not a very reassuring hostname. There is no reply to the request; the exchange stops there (at least during the six minutes or so that I left the trace running).

There is something wrong with the PDF procedures being served for our European customers, we’re working on it.

The bundled procedures are working for European customers now.

I found something else with Firefox 19.0.2 the current release. It has an internal js app for reading Adobe Reader files and does not necessarily do a good job. If you are having this problem in firefox, click help and enter “adobe reader in firefox” and go from there.

Hope this is helpful to someone.

Better yet, in Firefox 19.0.2 go to Tools - Options - Applications and change the PDF reader to Adobe or whatever you have on your machine. The Firefox PDF reader isn’t quite ready for prime time.