Got the same problem, for several weeks now and the same lines in the logs:

sync of http://foxtrot.mgras.net:8080/terrascen ... 40/e006n46 started, queue size is 7sync taking a long time:Models taken 20001HTTP status:1sync taking a long time:Objects/e000n40/e006n46 taken 20001HTTP status:1sync taking a long time:Models taken 30001HTTP status:1sync taking a long time:Objects/e000n40/e006n46 taken 30001HTTP status:0sync taking a long time:Models taken 40016HTTP status:0sync taking a long time:Objects/e000n40/e006n46 taken 40018HTTP status:0sync taking a long time:Models taken 50050HTTP status:0sync taking a long time:Objects/e000n40/e006n46 taken 50050HTTP status:0sync taking a long time:Models taken 60073HTTP status:0sync taking a long time:Objects/e000n40/e006n46 taken 60072HTTP status:0sync taking a long time:Models taken 70100HTTP status:0sync taking a long time:Objects/e000n40/e006n46 taken 70099HTTP status:0sync taking a long time:Models taken 80016HTTP status:0sync taking a long time:Objects/e000n40/e006n46 taken 80016HTTP status:0sync taking a long time:Models taken 90041HTTP status:0sync taking a long time:Objects/e000n40/e006n46 taken 90041HTTP status:0

Occasionnaly it works like a charm and the scenery gets downloaded, but most of the time, it failed.V.

yes, these showing "HTTP Status: 0" are what i've mentioned several times in the last year in a few different places...

IF you are building your own FGFS from the repo, you can try adding -DENABLE_CURL=1 to your SimGear cmake line... if you are using the download_and_compile.sh script, you can add it to the $SG_CMAKEARGS variable at the top (about line 50) of the script... what this does is switch the simgear code from using the built-in http client to using the external curl library... this is highly experimental and, AFAIK, only available in 3.7 when you build your own from the repo... you won't find this in the nightlies...

when compiling, you should see something like this in the output... specifically lines 47 and 48 at the bottom of this log snippet...

to disable using curl and switch back to the internal http client, set -DENABLE_CURL=0 and recompile...

PS: sharp eyes will note that i'm also using the repo version of OSG and that i have both optimized and debug builds in place

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

Right now I'm thinking that somehow downloading the scenery not using TerraSync is the way to go, and then turn it off when flying. Is that correct? I mean, the weird thing that I've noticed with this, since forever, is that if I'm flying for example across the US and have scenery already downloaded on the east/west coasts, if it starts fine and then drops out in the middle of the continent, it never reverts back to saved scenery on the other coast.

When tiles that you don't have don't load, tiles that you do have stop loading as well. But if you disable Terrasync (uncheck the box in the scenery download dialog), the tiles that you do have will load. If you have enough memory to load a second instance of Flightgear with the UFO, you can start the UFO at your destination so that you can at least land. Or plan ahead and fire up the UFO at your destination before a long flight.

We tend to call this a Terrasync bug, but it's a scenery loading bug. A frustratingly elusive one at that. Nobody seems to have succeeded in making it happen at will, which means it's virtually impossible to track down.

EDIT: another option is to use Terramaster to pre-download tiles. If you can get it to work. I only managed to get it to show the tiles I have.

Yesterday I found a missing scenery tile in Alaska. I had last flown there several months ago, when Terrasync was still reliable, and it had been cached for several years. I disabled TS from the menu and clicked Apply, but it still wouldn't load. I tried again today, and TS loaded the tile normally before I got within visual range. It seems to fail randomly, and at the server end.

FWIW, the tile across the Bay north of KNUQ hasn't loaded in a year or more. I assume the reason is different for that.

I tried a direct svn pull from the terrascenery server and it timeouts at each update. I also tried terrasync and this one behaves the same way FG does i.e. works occasionaly to poll the data but fails most of the time. It looks like this is a server issue on foxtrot.mgras.net.

@wlbragg, thanks for pointing the CURL option for simgear, I'll give it a try. BTW, flightgear needs to be recompiled too to include James commit to handle libCurl if simgear is compiled to use it.

vector wrote in Thu Dec 10, 2015 12:06 pm:BTW, flightgear needs to be recompiled too to include James commit to handle libCurl if simgear is compiled to use it.

yes, if you rebuild simgear, you have to rebuild flightgear, too... i use a script so it is all the same to me... eg: ~/flightgear-dev/updatenext which is my personal script...

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."