At least, the video card ram is one less probable cause eliminated, many more to go!

Something else to try out: is this on a default 'light' scenery or when flying in a 'third party' complex scenery?

Just to make sure, this only happens when you exit X-Plane with a GTN powered on, it doesn't happen when you exit X-Plane with a GTN powered off. Then, do you experience any delay when switch from an aircraft with GTN powered on to an aircraft without any GTN?

If there is no delay, then the issue must be related not to the GTN process itself, but to the plugin as a plugin in X-Plane, and the way both (XPlane and plugin) synchronize when they are shutting down.

First of all, hope, you had a fine landing, ...have my very best wishes for a happy, above all, healthy New Year - take care!

And with respect to the topic:

It's default scenery, no Ortho or other demanding stuff installed.

Yes, you're right, it only happens if leaving a GTN-active situation, i.e. either quitting XP or changing to a non-GTN-active aircraft. (Admittedly, I've not yet checked the transition from a GTN-active aircraft to another GTN-active aircraft.)

 

Any news or suggestions?

On January 1, 2018 at 11:28 AM, Babbo said:

Admittedly, I've not yet checked the transition from a GTN-active aircraft to another GTN-active aircraft.

Hi, this would be an interesting test although I suspect you'd get a delay as well. Can you please cross check this?

XP11-loading completely normal, C172 with active GTN again normal. Switch to EMB110 with non-active GTN about 40 secs. Then, after enabling GTN, switching back to the same C172 (i.e. from active to active) about 5 minutes 50. Finally, quitting XP about 50 secs.

All in all, more than 7 minutes idling ... Simply, too much.

This confirms this must be something 'acting' on your system when the trainer process closes then. I'm sure now you can experience the same 'idling' when just powering off the device (turn off avionics/batteries with GTN Settings 'Battery' set accordingly): doing so also closes and re-start the GTN trainer process in the background.

Since we don't have widespread reports of such problem, and in fact you're probably the only one reporting it so far, this leads to the operating system. Usually, when this occurs, there is a great chance there is a process-wide hook in your system, that is something that gets 'injected' in every single process running on your system. This can be an anti-virus, a virus, a tool (such as augmented/assistive functions), etc...

 

Here we go:

You're right with your first paragraph: using the plugin menu for ON causes no delay, but any OFF-setting considerably does. Regarding, the battery switch (accordingly invoked), the behaviour is somewhat erratic: OFF always works immediately, ON (after OFF) causes freezes and even crashes of XP11.

Your "hooks". Checked that with intensive commitment: antivirus, defenders of all kinds, services, processes (handles, mappings ...) in general. Not a single cause found. (Actually, I would have been surprised, this is my dedicated machine, everything is well maintained and literally no issues are present.)

May I remind you of our early discussion, my initial Black Friday discount problem ... I would be willing to invest into a 650 - as discussed - and check that one for a maybe better coexistence with my stubborn system!?

The GTN 650 wouldn't function differently for that matter. The only other thing you might want to try is chancing the CPU affinity in case something is interfering but I doubt.

Default setting is 'automatic' which works fine for all our customers so far. This setting is only edited in the ini file directly, follow the embedded ini file comments for the setting value.

Other than this for now, we've eliminated a number of probable causes and it is getting harder to find out what is happening exactly.

 

3 hours ago, RXP said:

... 'automatic' which works fine for all our customers so far. This setting is only edited in the ini file ...

Which 'automatic' do you mean and which ini-file?

This is explained in the User's Manual: the RealityXP.GTN.ini file created and managed by the RXP plugin in each of your aircraft folders. It contains all the plugin settings per-aircraft, most of which are managed through the GUI Settings Panel, some of which are manually edited in the file using any text editor like notepad.exe

Each setting entry is in the form name = value and has a self-documented line right above explaining the purpose and the available options. Look for 'CpuAffinity' 

Thank you, will check it.

Hi Jean-Luc,

I have had this problem for a long time but as it only effects switching off I have lived with it.

Just done a CPU check, I have GTN 650/750 GNS 430/530 but for this test I will only check GTN as do not have a problem with GNS.

First start as default with CpuAffinity -1 auto and I can see CPU 7 and CPU 8 are running the GARMIN, switch off battery and both CPUs go to 100% for about 5 seconds, switched battery back on and all is working. Closed down X-Plane and CPUs 7 and 8. go to 100% and computer locked-up. 

Restart and set CpuAffinity 8 for both 650 and 750. This time thing work better with only CPU 8 in use. Battery off went to 100% for about 3 seconds, closing down X-Plane it went to 100% for about 15 seconds and then closed down. One thing with just one CPU now running the GARMIN, I do not get the last screen lock which I have had for a long time.

Need your advice on which CPU and should two be running. As I said no problems with GNS.

Tom.

Hi Tom,

First, let me wish you a happy new year, and thank you for these precious details!

There was a bug in some previous version with the 'auto' setting effectively wrongly setting the affinity, which is supposed to be corrected since the latest GTN version 2.4.12. Have you updated to 2.4.12? 

The 3 to 15 secs ressemble normal operation!

Yes 2,4.12, always update as soon as it comes out. Should it run on two CPUs? Also I do have an old computer, over 6 years, should the CPU go to 100% on switch off?

It is supposed to run on one CPU only, as for the 100%, I can't tell if this is normal or not, but closing the process requires writing and flushing  a certain quantity of data to disk, which might consume a lot of CPU depending on your disk drive technology/bus, and it also requires syncing a certain quantity of data/state between the trainer process and the plugin which might account for some CPU use spikes. When done, Windows also has to sync a certain number of other things related to process and window managements, and to top this, it also has to discard/flush all video card objects (textures, frame buffers, etc...). As a matter of fact, powering off the trainer (not closing it when exiting but only powering off in sim) requires not only closing all mentioned above, but also launch the trainer process again in the background waiting for power on command. Launching the trainer therefore also consume some resources as the process is reallocating video card resources, opening and reading files (DB for example), etc...