aivlasoft

Although I have no more installation of P3D, I can try it. Nothing promised ... ;-)

Thanks for providing the solution. I'm sure it will help others when they experience similar issues.

Thanks for lettings us know that it now works.

Hi Ray I guess that this one can help: https://forum.aivlasoft.com/topic/4264-why-are-ils-approaches-not-showing/

Maybe this one, from the FAQs, will help: https://forum.aivlasoft.com/topic/3069-navdata-installation-paths/

Traffic data is received from X-Plane, and if flying online with either VATSIM or IVAO, additionally via the respective online network (please see the Client manual for in-depth information about online traffic). In either situation it is beyond the scope of EFB how many aircraft symbols are available and where they are located.

Hi Jeff Do you mean that only the aircraft on ground are depicted but not the aircraft which are airborne? Maybe a filter setting?

I guess the images come from rainviewer.com. Unfortunately these images are raster images which cannot be applied onto a sphere without converting them before (which is quite time consuming and therefore not possible at runtime).

Unfortunately a rebuild will not solve the issue because the fixes are taken from either Navigraph data or Aerosoft data and this data remains untouched. I 'fear' we have to live with what we get from them.

I'm sorry, no. This is a Windows limitation. The only remedy of which I know is to reinstall MSFS to a location other than the default path (e.g. C:\MSFS).

When creating the database, EFB is trying to eliminate such 'duplicates' but if their position differs only a little bit, than they will no longer be recognized as duplicates. From the screenshot provided I can see that not all of these doubled fixes have the same identifier which might be the cause for the 'duplicates'.

EFB (and other add-ons using FSUIPC as an interface to MSFS) can only read/write to standard COM frequencies. If an aircraft does not use these standard 'offsets', we cannot do much.

Hi Rolf it could also have been a formatting error on SimBrief's side. The XML-file which will be downloaded when importing a flight plan is also not set in stone and sometimes it is undergoing maintenance. Anyway, hopefully it works again for your flight back to EDDK.

Thank you for testing EFBv2. Unfortunately I have no Steam installation so my advisory is also taken from the search function of this forum. I guess that this thread will help to figure out the required path (it is worth to read the entire thread):

Profiles can easily be created (or updated) using the Profile Editor. Especially if one owns the respective aircraft then usually the developers will provide the kind of information which is required to create/update a profile. We do not have all these aircraft.

Hi Iain I assume you mean the 'calibration' caution/warning on the sidebar? This is an option which can be activated/deactivated in the A/C profile. Just run the profile editor and update the A/C profile accordingly.

@romoni Do you use the integrated import function in EFB, or do you copy/paste the routing string? I just did a quick test and created a route from ESSA to EDDK in SimBrief. Although the ICAO formatted flight plan contains the KOPAG2V arrival, internally it will be recognised and removed so I'm finally getting the following routing: ESSA DCT PETEV N872 ELPAX Z703 UMIXA DCT KULUD Z703 ALS M852 POVEL Q201 PODER Z189 RUNER T858 KOPAG DCT EDDK. To remember, EFB does not import procedures (neither DEP nor ARR). Procedures always have to be selected/added manually using the PROC-dialog.

There is no specific start sequence required. I would not delete the profile but move it to another folder instead.

It looks like MSFS provides different aircraft codes for different liveries. I haven't seen that before. From the first logfile I see that the following codes are provided: b738 737 b736 If you don't use the profiles for the 737-600 and -700, I suggest that you remove these two profiles and then add the aforementioned codes to the profile for the 737-800. This way the profile for the 737-800 will be selected in either way.

I don't think that the liveries are the cause for the issue, because a livery is 'just graphics', not logic. But to be on the secure side you can try whether the issue also happens when another aircraft (other than the PMDG 738) is in use. Are you running other popular add-ons while EFB is running? e.g. LittleNavMap, SimStarter, any AI-Traffic generating tool, etc. FSUIPC is used for the connection between EFB Server and MSFS. The connection between EFB Server and its Clients does not require FSUIPC.

According to the log file the name of the AIR-file (which in fact points to the aircraft.cfg) changes several times but I cannot see why. It 's always the same sequence, the first read seems to be OK, it returns the full path to the aircraft.cfg which can be utilized and then, some minutes later, the AIR-file name changes again, but then only a relative path is provided which cannot be utilized, hence the aircraft.cfg cannot be read. Whenever this happens, the Server is trying to get the information about the model from FSUIPC internal variables which obviously are not properly set. I have no idea what is causing this re-reading and/or changing of the AIR-file name and I also have no idea about FSUIPC internals. The first thing that should be found out is the reason for the changing AIR-file name. Are you running any other MSFS add-ons which might be the cause for that? Can you try running MSFS with EFB only?

I have the same log entries because it is the default database.

The folder XPAPT is not meant for placing the earth_nav.dat file. It is meant for certain/single apt.dat files. For details please see the manual "4 EN Database.pdf", chapter 2.7 and 2.8. According to the logfile entries I have to go the way to eliminate all possible reasons and therefore the first step is trying to create a database without any errors. As I already mentioned before, the error at the Client happens when the program is trying to access a certain airport which obviously is not present in the database. If an airport is not present in the database points to an error at the creation process of the database. When you strip out the extraneous information all the alternate airports are no longer part of the flight plan and therefore the program is not trying to access them. Most likely this is the difference and the reason why it works then.

Thanks for uploading the files. It is indeed an error which is causing the map drawing process to exit before it has finished. The error happens because it is trying to read an airport from the airports database but this airport seems not to be available. So my idea is that something must have happened when the database was created. I can see from the logfile that an error was logged when the DbBuilder was trying to analyze the folder 'XPAPT' in the Servers directory structure. So the question is which airports are in this folder and can you give it a try to rebuild the database without these airports?

I have no idea why the runways have these identifiers. Maybe the creator of the scenery can help. But anyway, it's not important for the database building process. The database will be built despite of the warnings. Just ignore them.