lonewulf47

Yes indeed. That's why this access is editable and needs to be properly set by the user.

Also inflight? A few buttons on the RSB (Routing Shortcut Bar) are only active if you are inflight.

Hi Jean Gabriel, That all looks very strange and by no way reproduceable on my side. Could you please start the DbBuilder and make a Screenshot of the available databases?

Hi Dirk, Please use the search function on EBBR and have a look here: https://forum.aivlasoft.com/topic/3005-afcad/

Hi Michael, Yes, this is nothing mysterious. If an AddOn Designer decides to draw a few more lines on his ground layout, he uses the ADE option "closed TWYs" to avoid AI traffic to use these "taxiways". This will draw a red line. Not a very common way, but alas - we are not here to critizise the Add-On designers ... 🙂 No harm is done to neither ground layout nor the taxiway system...

FsAerodata is an Add-On. If you don't have it installed then it's ok. Please send a set of Support Files and post it here: https://forum.aivlasoft.com/topic/3046-how-to-create-a-support-file/

Great to hear. Thanks for reporting !

Do you by chance use FsAerodata? https://forum.aivlasoft.com/topic/3887-fsaerodata-is-not-compatible-with-efb-v2/

yes, all ok now 🙂 I found my presumption confirmed. If you are able to use a simple text editor on a text file, then do the following: - navigate on your Laptop to the folder "C:\Users\reinh\Documents\AivlaSoft\EFB2\Client\Settings - within that folder open the file "ClientSettings.txt" with a text editor - in the [Network] section look for the line "TcpPortNumber = 57892" - change this number to 51748 - save the file and start the Client. It should connect now normally to the network If you are not familiar with text changes, just post the ClientSetting.txt file here and I'll do the changes for you. The background of this story is the following: At some point we had to change the TcpPortAdress for technical reasons. We decided to leave the old (51748) PortAdress while all installled systems remained in the automatic update process. Now that you enlarged your network by a freshly downloaded (I guess at least) #118 Client, the new TcpPortAdress 57892 was installed for that client. Therefore the new Client was looking for a connection on that port, but of course couldn't find any. Actually which TcpPortAddress you use, whether the old one or new one is of no importance. Server and ALL Clients however MUST ALL use the same port number.

Please also note that a re-boot of the Server Computer will most probably reset the Socket Exception. The "Collision Risk" as described in the article however remains. Changing the TcpPort Number will most probably be the better long term solution.

https://forum.aivlasoft.com/topic/3046-how-to-create-a-support-file/ I have however another assumption. Are you familiar with editing simple text files? I guess you updated EFB2 all the time properly with the automatic update feature. Therefore the old TcpPort number is still in use. But to make sure about this we would require the two support files, 1 from the Server and from the Laptop Client.

https://forum.aivlasoft.com/topic/4032-socket-exception-only-one-usage-of-each/

Hi Reinhard, I'm sorry but according to our Forum Rules all requests and contributions must be made in English. To solve your problem, we require some more information. I take it that you are working with the newest build# 118 (Server and Client). When opening the Client for the first time, the window shown below should have opened: There is actually nothing else required. Just make sure you are really on the same build# for Server and Client. Either way a set of support files from the Server and the Laptop Client would be helpful.

I take it that you are aware of Hervé Sors' Navaid Updates (including regional ILS updates): https://aero.sors.fr/navaids3.html This way you have all Navaids updated at each AIRAC cycle. Of course especially regarding ILS' this is not affecting Add-On airports, but that's the same with fsAerodata.

Hi Romain, You can upload it here.

There can of course be a considerable difference between P3D and X-Plane. Depending on the number of Add-Ons you have, one database may be much bigger than the other. I would presume that the X-Plane database might be bigger in size. This in connection with a somewhat limited network can lead exactly to the reported issues. This would also explain why it works flawlessly in local connection but not networked. As Urs already explained your network seems to be at its limit when it comes to this kond of filetransfer. Just let me make this clear to you: Nobody is accusing you for lying to us. You must however understand that we cannot provide remote troubleshooting if we do not see INTO your systems. What we COULD see with the help of our Support Files is what Urs stated already: Your (WLAN?) nework is at its limits. This led to the errors that are visible and reported in the Support Files. Now what else do you expect from us? We do lots of testing on our end and of course also in networked configurations. None of our tests has ever revealed the troubles that were reported from your Support Files. So again: What do you expect from our side? We can't do more than analyzing the data available to us and draw the respective conclusions.

What does EFB Client show in the status window (top right corner), at the moment when the A/C is not moving? Is there any AMBER message? If not, then we need a set of Support Files.

Hi R.H. (please observe our Forum Rules and sign with your proper name) EFB2 indeed uses the taxiway information supplied bythe so called "AFCAD" BGLs provided by the Add-On Developers or by the simulator's default library. As these AFCAD files are also used to control AI traffic ground movement, it is obvious that some Developers have their own rules as to how they will restrict the AI traffic in their movement freedom. This unforunately also leads to interrupted taxilines, although they are of course not interrupted in reality. The reason is to avoid AI traffic to use these taxilines. The only remedy for that is to produce your own AFCAD BGL and place it into the respective folder in the EFB Servers document file structure. This AFCAD BGL will then exclusively used by EFB2 to DRAW the ground layout, but it will not influence the AI traffic within the simulator.

Sorry, Brian, I'm still talking about the Support Files, not the LogFiles. In one of the messages above I posted a link to our FAQ, where creation of Support Files Is described. Support files contain more contextual information than just logfiles. In this case both Support Files for Server and Client would be helpful.

Please again, send a support file, not a single line from a logfile.

Hi ??? (please observe our Forum Rules) I cannot duplicate such behaviour. Here the data for X-Plane is perfectly synched. There is no entr for airways. It's more likely that you refer to the aispaces.bin which is correct at 0.0 kb. What do you mean by "the client will time out"? How is this displayed? If the Client is affected, of course the Client's Logfiles would be more helpful. Neverhteless whenver possible use the Support Files Routine for either Server or Client or both.

Great to hear, thanks for advising 🙂!

Hi Luke, The availability of Approaches is unfortunately not in our hands. It depends on what the data provider (Jeppesen or Lufthansa/LIDO) is willing to include in the selection. ATM for Queenstown I don't see the mentioned RNAV Approaches in the 2005 cycle dataset for neither NavDataPro nor Navigraph. So they're simply not included. Why they are available in the FSL MCDU is beyond my knowledge. Maybe a special agreement by FSL.

No, because the installer put the path name into the add-on.xml and the add-ons.cfg to remain consistent with the complete install - unless you are going to change this manually too. But I do not recommend it at all. You wll create a lot more problems if you mess-up with those files. So a uninstall and reinstall is definitely the easier way and it takes ony a few minutes.

Well, this database was built on may 5th, 2020, at 18.58 hrs. It contains 2 warnings, because it couldn't find the paths for EDDK Cologne and LSZH Zurich because you created "private" installation paths using mutated vowels (Umlaute) like Köln, Zürich. As we are using an standard typeset for international use, mutated vowels must not be used. Standard installers do not use such letters either. I will check on the displayed Database Creation Date. There's maybe something missig due to the warnings. I'm afraid you must reinstall EDDK and LSZH into paths witout mutated vowels and everything will run smooth again. Maybe you didn't even notice that EDDK' Ground Layout was not displayed properly either. What you saw for LSZH was the default Ground Layout with two default ILS outdated. Please note that if after Database Creation a warning is displayed, it should be corrected. That's what the Logfiles are for 🙂