I am not sure my findings fit 100% this header (I would have called it "TerraSync and Memory/Loading") - but I guess that are the same symptoms! So here my dime:
As ATC at EDDF I get a lot of visitors - and noticed that more and more people crash when getting close to EDDF - so I tried to find a reason for it:
So I gathered as much data as possible and placed those onto my homepage - You may download
http://www.emmerich-j.de/TerSyn-Analysis.zip - I will keep that up there this month (and then delete):
- see especially my
PC-data in the Sub "SysInfos"
- and the Start-File "Biggy.sh" ( I do not like the FGrun - it's startup is always very time-consuming!)
- for my
Scenery Status see:
"--fg-scenery=/home/emmerich/FGFS/Scenery/eddf-ellx:/home/emmerich/FGFS/Scenery/TerraSync:/media/emmerich/Central/FGFS_S \"
-- eddf-ellx is a AddOn to EDDF
-- TerraSync was build up new from Scratch when new scenery became available by TerraSync
-- FGFS_S is the "whole world" in the old style!
- my
INTERNET-connection is an 16.000 unlimited from 1&1 via a Fritz 7390, PC is connected via LAN.
I guess in general that is "a medium equipment for FGFS" (slightly at the upper edge).
1) I flew some patterns around EDDF (EDDF -> RID -> CHA -> EDDF) and noticed each time a "Segmentation fault"
near VOR CHA, just when crossing the 8°30' east. Looking into the attached
fgfs_0.logBU I noticed constantly repeating errors for port 5505 and 16661 (was needed before 3.0 for ATLAS+TerraSync and FGCom). So I removed those - then I could complete my Pattern - and did not ever get that Problem back - even when adding those two definitions again. So:
-->
seems that these "port errors" prevent TerraSync from loading new stg-files--> is 5505 still needed for ATLAS ??
--> will 16661 be needed again in future for the final FGCom ??
--> wouldn't it be enough to report that "errors" once in the header - and not just mess up the whole LOG?
2) Then I tried a new route "EBBR to EDDF" (where I had no data yet in TerraSync):
a) TearrySync1: As in "Biggy.sh" -
without the 2 ports:
--> Seg-Fault while loading stg-files
- after several stg's were already loaded without problems
- (no idea why it did not find the "..Central/FGFS_S" with its worldwide "Terrain" + "Objects" - but obviously that does not have any influence onto the problem - so I do not care (for now))
- see the "Memory" slowly raising while "Receiving" is active
- the "CPU1" each time gets limited at 100% while loading
b) TearrySync2: As in "Biggy.sh" - I found in
http://wiki.flightgear.org/TerraSync that I may have to use the
extra "--terrasync-dir=.." - so I did:
--> "Seg-Fault while loading stg-files
- But interesting: Comparing the fgfs.log from TerraSync1 with the one in TerraSync2 you notice that this time the problem occurred later - i.e. it is not a fault in the scenery-files - but terrasync obviously can always only handle a certain amount of NEW stg's !
c) TearrySync3: As in "Biggy.sh" - but just to make sure there is no problem when using old/new scenery I
removed all other scenery-dir's except the "TerraSync" (containing only new scenery!):
--> same result
- so it seems definitely that TerraSync is very much limited in the amount of downloading new scenery (at a certain speed/time !?! - BUT 380KN SEEMS NOT THAT FAST!!)
My conclusion:- I) Is it possible to make that TerraSync Fail-Safe?
- at least report a real cause prior to crash ??
- even better: If you cannot download in time just stop FGFS (like PAUSE) and continue when loaded - not nice for the user - but if you maybe display the reason on screen the user may forgive you!
- II) And see the constant upload into memory!
Should there also be some download again after some time? Memory cannot raise unlimited during long flights in new terrain!
pls tell me if you need more data - I will be glad to help
thx for your efforts (and the new scenery looks a lot better)