Loading forever: "loading navigation data"

[digibill]

I just installed flightgear 2.12 on ubuntu 13.04 (I used v2.4).When trying to launch it, it loads forever at the point where the splash screen indicates "loading navigation data" (with a / rotating beneath) and the terminal gives "Enabling ATI viewport hack". It does not freeze, it just keeps rotating for looooong.....
My system is Ubuntu 13.04, Athlon x2 5.2GHz, nVidia GeForce GT 640 2GB GPU, 3GB RAM, flightgear 2.12, and the problem seems to occur whatever airplane/airport I choose (I tried 2-3 different) .

Any ideas?

[zakalawe]

How long is forever?

Depending on your hard-disk performance, this step should take 1-3 minutes (and once it's done, it only occurs again when some data files change). There have been bug reports about it sometimes taking much longer but unfortunately no one has been able to track down why it's so slow for certain people. If you home directory is setup in an unusual way (mounted over NFS or SMB) it will be a little slower but again should only be a few minutes. (Conversely, if you have an SSD it's very quick, about 40 seconds total here)

[digibill]

That sounds logical... I'll make another test and will try to define "forever"

[Hooray]

the log file should tell you how much time was needed for the navcache rebuild

[digibill]

Well, you were right! After some 5-6 minutes it finally started! I couldn't imagine that this is normal!
Sorry for the inconvenience, problem solved

Thanks a lot!

[zakalawe]

Well 5-6 minutes is definitely not good. I'm going to work on adding a progress indicator so at least people realise it's taking a long time. Can you mention anything about the IO setup driving your home dir? SSD? SATA? Network share? Any anti-virus software running which monitors disk activity?

1-2 minutes it normal, 3 minutes is bad, 5-6 is unusually bad.

[Kabuki]

I installed flightgear on an external hard drive, instead of my internal SSD this time, which I'd done with previous versions. The first thing I noticed was a much longer loading time, and was about to conclude that it's because of the different drives.

Loading times, both using the Dragonfly, at PMDY (about the fastest loading combination available to me) on the external drive.

version 2.12
1:30 -- finished loading navdata -- this was the first time 2.12 had seen PMDY.
1:59 -- ready to go.

Version 2.10, loaded from internal SSD
1:07
1:30 -- ready, counting fade-in, which doesn't seem to happen in 2.12

Not a very good experiment, because there are two different variables there. And the scenery was loaded off the SSD in both cases. What's surprising to me is how *little* difference there is,

On a hunch, I started 2.10 a second time, (same plane, same airport, immediately after closing flightgear completely and restarting it) and was ready to fly in less than 18 seconds.

So I tried it again with 2.12 and did a couple of tests with a complete shudown of the launcher between tests, and the loading time from 'run' to 'ready' was about 1:45 both times.

So it seems there's some sort of 'cacheing' going on in both versions, but it seems to make more difference in 2.10 than 2.12. Note that I was using the terrasync directory on the SSD in both cases, but the scenery directories were both changed to their respective install directories.

----

The reason I installed on the external drive this time was that my SSD is pretty full. I was hoping to move all the Terrasync files to the external, since they're taking up the most space. Hopefully, scenery will load fast enough from that.

[zakalawe]

The loading system hasn't changed much between 2.10 and 2.12 - we added an additional data set which makes the first run take longer (adds points of interest, i.e cities & towns, to the map and GPS systems). But the 18 seconds for all runs after the first should be the same for 2.10 and 2.12. (There is an occasional bug where we take two launches to build the cache, instead of just one, but that I'm fixing).

I word repeat your measurements a few more times, and if the times for 2.12 remain substantially different from 2.10, you have something weird going on, and should file a bug report, including the startup log with --log-level=info.

[digibill]

Well 5-6 minutes is definitely not good. I'm going to work on adding a progress indicator so at least people realise it's taking a long time. Can you mention anything about the IO setup driving your home dir? SSD? SATA? Network share? Any anti-virus software running which monitors disk activity?

1-2 minutes it normal, 3 minutes is bad, 5-6 is unusually bad.

Well, an indicator and a warning that this process is going to last a bit long would be good...

My installation of flightgear is at my home folder, which is a typical SATA drive, nothing special here... I have three SATA drives on my motherboard (and also 2 IDE) and maybe my SATA controller is overloaded?

[Kabuki]

Something's definitely changed with the loading navigation data phase of startup. It's now taking me around 2 minutes to start with a Dragonfly at PMDY, where it used to take about 20 seconds or less. I notice that once the loading navigation data is finished, it takes about 20 seconds from that point to being ready to fly.

This is with a clean, clean installation. I removed all traces of former flightgear installations, including some artifacts in the registry that CCleaner found and defragged the SSD, turned off the virus scanner...

The first launch, I flew the Dragonfly from KHAF. Using terrasync, I loaded the airport and stuff for PMDY, and tried both places again. There was no noticeable difference in loading times, after launching from both places several times.

[zakalawe]

It's now taking me around 2 minutes to start with a Dragonfly at PMDY, where it used to take about 20 seconds or less. I notice that once the loading navigation data is finished, it takes about 20 seconds from that point to being ready to fly.

What happens on successive launches after the first one? it sounds as if you're experiencing a nav-cache build *every* launch, which would be bad, and needs to be explained. It's something related to particular setups, but you will need to figure out what. Running at log-level=info should tell you why the cache rebuild was triggered (scenery paths changes, timestamp of a data file changed)

[Hooray]

there's a log file in $FG_HOME, post it here

[Philosopher]

Yeah, that one's even more useful.

James: when I switch scenery directories (like automatically, e.g. starting at WSSS using omega95's contribution in some random directory, versus KSFO-default in $FG_ROOT or a different external directory), does it have to reload? I think I found that it did, which I would think is something that could be improved: the scenery hasn't changed, just the location we are loading it from, so we might be able to cache it for different scenery dirs too. Or is it generated from all sceneries, in which case it shouldn't be reloading at all?

I think this problem might be afflicting Kabuki: have you tried loading from the same place twice?

[zakalawe]

When the scenery paths change, we have to rebuild, because Airports XML data (from the <scenery>/Airports/ tree) is overlaid into the cache, replacing the data from apt.dat. This means when the search paths or order changes, we have to completely rebuild, because there's no way to restore the unmodified (prior to XML overlay) version. I consider the time and fragility to implement such a system much greater than the impact of a rebuild when switching scenery paths, which most people don't do very often.

(Of course people who switch scenery several times a day would disagree, but my perception is that's almost no-one)

Okay, I just thought of a crude solution - I could clone the DB after initial load (physically on the disk, basically a 'cp' command) - and when the scenery paths change, overwrite the DB with that version. This would burn another $cache_size worth of FG_HOME space (currently about 100MB) but most people wouldn't care I guess. Again I'm not convinced enough people change scenery paths often enough to make this a big deal, but I'm open to being convinced otherwise, it's probably only an evening's work for me to add.

[zakalawe]

(And to be explicit, startup location is totally unrelated to the above, it's ONLY the --fg-scenery paths that trigger it)