EnQ

LSGG ILS 22 has its CAT 1 minima covered by the same arrow in both the Windows app and also if viewed in the browser (although rendered on server side).

Looks like there are even more font rendering issues... In both the Windows app and the browser version (Chrome) visual tracks currently appear with letter "Z" instead of the expected arrow markings, for example: LOWI "Visual after LOC DME" charts LOWS Circling 33 (but RNP V 33 shows the arrows correctly) LFMN Circling approaches Other LFMN approaches show the number "2" overlaid on the NDB NC which I can't make any sense of and don't remember having seen something like that before. It's kind of weird that both the old rendering in the Windows app (still PDF, I presume?) and the newly generated JPEGs are affected... Might be some new generic issue for AIRAC cycle 2001?

LYBE AGC is also blank using either Windows app or Chrome. Again, I can see that the downloaded PDF is empty except for meta data. Affected files have just 1.3kB which makes me think all blank charts should easily be detectable on server side by checking for charts smaller than 2kB.

Charts "AGC" and "Tempo AGC" are blank for ESGG, both in Windows app and Chrome. Using Chrome's developer tools I can see that the PDF appears to be without content (just metadata). Other charts of ESGG are fine and I didn't notice any other affected airports yet.

For EDDT charts "ILS or LOC 26R" and "ILS or LOC 08L" a part of the CAT minima is currently covered by a large black arrow. Is that arrow supposed to be there or some rendering issue with those documents? The small arrow in the right lower corner refers to "additional minima [...] on the last IAC page" (i.e. "WxMinima Overflow") according to the 2014 LIDO documentation I have at hand but it seems that the large arrow is somewhat out of place (especially since it covers numbers which I would not expect on aeronautical charts). The arrow is visible in both the Windows application and when accessing the webpage using latest Chrome. I already noticed that arrow yesterday before access to/rendering of the charts was restored. The chart pages have become effective in June and August, but I am not aware that I would have seen that arrow previously. "WxMinima Overflow" does not list Cat 2 for 08L so I don't think that arrow should mean to substitute any information.

Eigenartig, dass der Fehler so uneinheitlich ist. Bei mir funktionieren KSFO und KORD im Browser bestens, nur in der Windows-Anwendung wieder nicht. Edit: Im anderen Thread grad gesehen, dass ein Kompatibilitätsproblem zwischen den Browsern und Schriftarten der PDFs vermutet wird.

Im englischen Forum wird grad schon versucht, dem Fehler auf die Schliche zu kommen: Wenn Du die Charts dringend brauchst, versuch es mal im Browser unter http://navdatapro.aerosoft.com/ - das funktioniert zumindest bei mir erstmal ersatzweise. Bitte im anderen Thread auch nochmal posten, welche App Du benutzt oder ob Du auch auf der Webseite das Problem hast und wie sich der Fehler bei Dir äußert.

For me the issue looks the same as in yesterday's screenshot posted above: When using the Windows application I get a white screen when selecting certain charts. In such cases, "Downloading chart" is shortly visible but then simply disappears, leaving the page blank. No percentage is shown. For other charts I can observe that additional to the "Downloading chart" message a percentage appears and quickly counts towards 100% before the page appears. When using latest stable Chrome on the same machines (tried on two different PCs) the same charts work without any issues (navdatapro.aerosoft.com).

Just checked, LICJ is broken for me as well. LROP is also showing the same issue as yesterday, as is KFJK. New one: LSZH is missing APC chart for me, AGC and AFC are fine. A few weeks ago it sounded like there was a bigger issue on the server (drive defect or something like that) but that would not really explain why some clients can access the charts and some can't (even on the same PC and after all the desktop app is just nothing but an embedded Chromium browser, so why does it work with Chrome on the same machine...). I also noted that when accessing by web browser I see a "dark mode" option and a few days ago I noticed a green airplane icon (supposedly some preparation work for geo-referenced charts?). I don't have either in the installable Windows app. Could it be that the installable app versions cached some old resources (JavaScript?) which are incompatible with latest server-side API? If there's any way to open the apps up for Chrome's web developer tools I'd be glad to submit screenshots of the network and console log tabs, if insight from affected installations is needed. (TeamViewer or something similar for a developer to debug on my machine would also be an option - contact me by PM if interested but I can only offer access in the evening)

Seems to be a bit on-and-off right now. Working: EDDT, LIRN, LOWI Not working: LROP, KJFK No error shown in the NDP desktop application. Just tried again a few minutes later, now I get some more charts of the affected airports on one PC but not the other. Access through webbrowser appears to work fine. LROP AFC, AGC and APC charts appear to have the most reliably reproduceable issues for me. Also note that somehow charts have different names and appear in a different order in browser and app, is that normal?

Same here. Just in case it should be an account or ISP related issue: I got 304 days left in my subscription according to settings page (bought on 22 August 2019). App version 0.1.1; just tried reinstalling "1.0.0.1" (latest download offered) from the shop, app still shows 0.1.1. ISP: Deutsche Telekom, IPv4+IPv6 Dual Stack via VDSL (no mobile proxy) I just tried https://navdatapro.aerosoft.com/ through a web browser; connection runs via IPv4. Status code is 200 but the server says all PDF files were 0 bytes in length (content-length). Filenames in content-disposition header look correct.

First of all, a little disclaimer: I know almost nothing about Airbus systems and even after partial reading of a Thales FMS manual found on the Internet I am still not sure if what I observed are real issues (bugs) with the simulation or if it is actually simulated correctly. Maybe there's even some form of PEBKAC involved; I would be grateful if someone with more knowledge of the Airbus FMS could help to figure out which of these observations are bugs, expected behaviour or pilot-induced errors. I captured the following possible issues in a video. Unfortunately, I just noticed that for issue #1 I entered the actual expected EOD as constraint to the correct waypoint by coincidence (therefore, please ignore the comment at 1:05; EOD actually is at ARPEG, I just miscalculated the required distance when I added the annotation). However, the issue in general is reproduceable on different flight levels and in different descent situations, I just partially screwed up my bug documentation. Sorry about that, I hope it is still helpful... https://www.youtube.com/watch?v=-CvgmoeDcoE Versions are: Aerosoft A319 Professional v1.1.0.0 Prepar3D v4.3.29.25520 Possible issue #1: EOD displayed behind actual EOD on managed route To reproduce, simply dial in an altitude on cruise level and start descending in managed mode. Estimating the descent distance by calculating GS/60 * delta/VS instantly reveals that the EOD arrow is shown at a wrong position. My video shows that issue two times: Immediately after initiating the descent from cruise level (right at the beginning of my video), the EOD is displayed at a waypoint very far away. I am not quite sure if maybe that actually somehow makes sense in an Airbus FMS, so maybe that's not an actual bug. However, there didn't seem to be any constraints in the flight plan that would obviously hint at the EOD indicating some planned altitude instead of projecting the actual EOD. After having issued a Direct to a waypoint in unmanaged descent (V/S mode) behind the expected actual EOD (video: 2:30 - 3:00), the EOD appears to show at the correct location. Returning to managed mode (video: 3:30) pushes the EOD indication much farther away again. Looking at the FMS flight plan (video 4:00) shows that the estimated altitudes don't make any sense as estimations because those altitudes have already been left. The next constraint is FL140 at DOMUX. Maybe that is okay as well for Airbus systems, the question is: Should those altitudes show live estimations (as I think would be the case in a Boeing) or should they actually just be a one-time calculated vertical flight path? If the latter is correct, altitudes in the flight plan may make sense as they could have been calculated for a more shallow FPA towards the FL140 constraint at DOMUX at time of issueing the Direct. But then, why didn't the FMS try to catch the calculated path after returning from V/S mode to managed descend mode? If a more shallow FPA has been calculated, 1000ft/min is way too steep to regain & follow the vertical flight path. Possible issue #2: EOD remains on planned route when changing to HDK/TRK mode To reproduce, just change lateral mode from NAV to HDG or TRK while in a descend. Turning away from the original route shows that the EOD marker remains on the now inactive planned FMS route. From looking at the Thales manual it seems as if the EOD should instead be indicated on the ND's solid track line? That issue occurs two times in my video: at 1:15 after engaging HDG mode manually at 6:55 after FMS engaged HDG mode due to entering a flight plan discontinuity Possible issue #3: EOD skips flight plan discontinuity I deleted a waypoint to produce a flight plan discontinuity. The EOD marker appears on segments after the discontinuity (starting at 5:15). EOD this time seems to be projected to the correct position when laying it on the track by range instead of track distance (which cannot be calculated due to the discontinuity). Adjusting the altitude updates the EOD projection but only down to the first waypoint of the route after the discontinuity (6:05 - 6:25). I am completely unsure how a real FMS would handle that situation, maybe the simulation is fully correct in this case. Maybe yet another issue: Is it correct that segments after the discontinuity are shown with solid lines? They cannot be joined as long as there is a discontinuity in front of them in the flight plan. As already mentioned above, entering the discontinuity segment of the flight plan changes lateral navigation to HDG mode but the EOD remains on the then inactive track.