Captain45

I had to pause a flight midway from LGIR to EHAM; saved the flight for doing the rest the next day. I started P3D on yesterday's date and the time that I saved the flight. Active Sky was set on the historic date and time. However... AivlaSoft EFB had to load the flightplan. No problem. Continued where I stopped yesterday. But... the time in the top right corner is the system time of the Server PC and not the UTC time that shows on the clock of my B738 cockpit. Restart the EFB doesn't solve this. I think it's a bug, although a tiny one. Dirk

After a complete rebuild of my 'FS-SERVER' PC and install of the latest build, I have the issue that the Client (unchainged on a networked PC) keeps on waiting for the Server. The PC name of the server is correct and the port numbers are the same on both. Windows Defender has approvement for the Server. This really puzzles me, although I had something like this in the past. Can't remember what the solution was. Help will be very much appreciated. It's the same as in Nov.'21. But this time I changed the portnumber on both into #51465 which worked back then but not now. Still 'waiting' after restart both. Got it!!! In Defender/Advanced/Rules incoming there were 4 entries for AivlaSoftEFB-Server. Two of them were blocked. Made them active 'et voilá' it works. Pffftt. Dirk

Could be. I recently installed Proton Drive and that one might be the cause. Cannot think of anything else. To get rid of the open file issue I uninstalled and re-installed the client. It looks as if the problem is solved.

When I startup the client I get a popup reading: 'No access to the file ...clientlogfile.txt because it is in use by another proces. Sometimes it helps to restart the PC, but sometimes not and I have to restart the PC again. It's something that happens the last few days and never before. The client runs on a networked PC. I am 100% sure that I ended the previous session in a normal way.

@lonewulf47 Hi, Thanks for the insights. If you are using RDPresets EHRD on P3Dv.5 and not having a chart without taxiways, the troubles I had was probably by P3Dv4.5. Still... I consider it not very professional that RDPresets is not continuing support on P3D and have not tested with AivlaSoft EFB. Dirk

Hi Urs, I bought this product and after install I had a display in the EFB without taxiways and 'APT Filter OFF' in the top right corner. The producer wrote that they never have tested their product on AIvlaSoft EFB which I consider a bl....y shame. They have even abandoned P3D and are probably focussing on MSFS and do no longer support P3D. "Sort it out yourself", was the kind answer. I uninstalled the thing and put it in the trashcan. Just one question.... "Am I right that the APT Filter OFF message is because the AFCAD is incorrect?" and "Is there a difference for AivlaSoft in the way it handles AFCADs in P3Dv4 and P3Dv5?" Would be nice to know. After all I have spent a reasonable amount of time to get it work. All the best, Dirk

Sorry folks. I found the solution myself. Server and client were on different port numbers. I updated the clientSettings.txt to make it work.

@lonewulf47 Hi Oskar, You are absolutely right. In today's flight KJFK - KSFO (when filled in the ETD and EET) there was not so much difference between the planned ETA and the actual ETA. Apperently Simbrief did a nice job in predicting the ETA. That it took 20 min. extra had something to do with RWY10R. Coming from the east that means a large D-tour over the ocean. Planned was 28L or 28R. Greetings Dirk

Hi Urs, Thanks for the explanation. To be honest, I use FPLs created by Simbrief, so in step 2 I only insert the flightnumber. So I checked it out for today's flight and indeed, I ccan insert ETD and flight duration/ETA. Flying big iron, fuel on board is more in kgs/lbs than in HH:MM so I leave that one blank. But.... There are things like earlier or later times of departure, more or less tail- of headwinds aloft, other than planned SIDs and STARs, etc. So what's in the FPL is hardly never leading to a correct ETA. My advice would be, to take the calculated ETA (on the right side of my screen) and use that one in the TAF (left on my screen). Then both are congruent. Dirk

This is really a minor issue, but still... it's incorrect info. When flying with historical weather, on the APP\Weather\TAF popup I see f.i. 'ETA 09:55z' while on the main screen with the flight info it reads 'EET (ETA) 01:14 (19:12z)'. I think the program takes the PC time instead of the historical time, or.... it gets the info from ActiveSky and the problem is caused by AS instead of AivlaSoft. Greetings Dirk

Usually I don't look into the Server log. It's minimized. But because I had problems with UTLive2 I checked. I get this message sometimes 5 times within one minute. Then I see File based weather broadcasted. So it probably found the API. I run P3Dv4.5 + QW B787 + AivlaSoft Server on one PC (UTLive2 is OFF) and ActiveSky + ASCA + AivlaSoft Client on another networked PC. On both machines ports 19284 an 19285 are open sending and receiving. On the server PC the B787 weather radar works 100% and on the AivlaSoft Client it reads WX: ActiveSky so that's ok too. So, what could be the problem here? Busy local network? It's Gigabit. Dirk 2020-12-09 EDIT: I found the answer in another post. But it is still strange that I have to replace 'localhost' by an IP-adress while all comminucations between Server and Client work, including the IP of the client. Of course, that could be another client than the one where ActiveSky is residing. But this should be on the Server/Settings page below or above the link to the weather file. Probably it would be IP or (better) 'COMPUTERNAME'.to avoid changes in IP's.

Thanks Oskar. Indeed, that is the trick. To be correct, if you have a RWY extended to f.i. 25XT8 and you want a WPT in the APPR before that one, you have to click the 25XT8 (turns green) and then click on the map te be able to select the user WPT. I fact, that was exactly what I did, but.... DO NOT click the INSERT button on the FPL popup (which was what I did), because then the select is greyed out. It would be nice if the manual had been more clear on the subject. Dirk

I am running into this problem. When I right click (in the client's APP page for a small airport (SCCY in this case), that has no SIDs, STARS or FIXes, somewhere on a white spot on the chart, there is a popup that shows me f.i. 45 30,5S 071 54,3W. But the function 'insert as route waypoint' is greyed out. So I cannot add that specific point as a waypoint. Especially flying in mountainious areas to small GA airports it is essential that this is possible. The insert function in FPL only accepts Airports, Navaids and Fixes. However, when I create a flightplan in Simbrief (example attached for SCAP to SCCY) it has that kind of waypoints only. It is just to create a FPL that zigzags through vallyes between high mountains. AivlaSoft can handle that kind of a FPL. It reads WPTs like '*5433S07204W' and the like. It would be nice if there is a way to make the 'insert as route waypoint' function active by just right clicking on the chart. Thanks in advance, Dirk SCAPSCCY01.efbr

I made a flight with the QW B789 KSEA to KDCA and loaded the SImbrief flightplan in AivlaSoft EFB. Checking the destination airport I saw that the runways are coded in red (too small for the B789). But with low cargo and pax and autobrake at 4 there is more than sufficient RWY to land on. (Checked during approach when filling in the landing data. Didn't even need autobrake max.) So I took the challenge and made the flight with a succesful greaser on RWY 01 and enough RWY left after the full stop on the RWY. So far, so good. But checking the EFB Client there was no airport displayed. A blank page with only blue AI. This was probably because the length of the longest RWY is shorter than what the B789 needs at MLW. But my aircraft was far below MLW. I think AivlaSoft EFB takes it a bit too serious in terms of this subject. After all there could have been an emergency situation that makes KDCA the only option when KIAD is not available. Cheers, Dirk

The flood of protests against Navigraph's idea to cancel FMS Data has had an effect. FMS DATA will continued to be available in the same way it was until today. I think they learned a lesson. Cheers, Dirk Based on their email on today 19th of November