Jump to content
Sign in to follow this  
RALF9636

Please add a reset / restart option

Recommended Posts

As described in the other topic sometimes MCE seems to hang and is getting very slow to execute a flow.

 

I am still experiencing this, almost on every flight, to different extents. Sometimes barely noticeable, sometimes MCE completely stops to respond.

 

Symptoms of this phenomenon are:

- the execution of the flow is getting slow, i.e. sometimes more than 20 seconds between two commands

- the mute key is recognized only several seconds - sometimes more than 20 - after it is pressed

- the PTT button is not working any more for extended periods of time

- the voice recognition rate gets significantly worse up to a point where MCE understands all kinds of nonsense but not the actual command any more

- exiting MCE does not properly close the program. When restarting (after waiting a significant amount of time) it says that MCE is still running and I have to use the Kill-MCE-App.

 

Factors that contribute to or worsen the phenomenon seem to be:

- having the FO talk to PF3-ATC while or immediately before or after the execution of a flow

- giving a command while executing a flow

- giving several commands in very short sequence, in particular if it happens unintentionally when the microphone picks up some noises

- pausing the sim while a flow is being executed

- giving a command (also by the microphone picking up a noise) while the sim is paused

- using accelerated sim rate.

 

All these factors seem to have a persistent impact on the performance of MCE, cumulating over time. On many flights that leads to MCE being almost unusable when I reach the approach phase (whereas everything worked perfectly when starting the session).

Closing (and using the Kill-MCE-App when necessary) and restarting MCE (with the sim session continuing) always cures the problem and I can start again with a fresh and fast MCE.

 

It kind off reminds me of the OOM-errors we once had with the 32-bit sims. Is it possible that MCE somehow cumulates buffered data and gets overloaded at some point?

 

Nevertheless to come to the point of the topic title:

Until you find a way to further track down this problem it would be of great help if MCE could easily be reset resp. restarted from the UI or the right click menu (also automatically running the KILL-MCE-App if necessary). Is it possible to add such a function? 

Thanks!

Edited by RALF9636

Share this post


Link to post
Share on other sites
13 hours ago, RALF9636 said:

As described in the other topic sometimes MCE seems to hang and is getting very slow to execute a flow.

 

I am still experiencing this, almost on every flight, to different extents. Sometimes barely noticeable, sometimes MCE completely stops to respond.

 

Symptoms of this phenomenon are:

- the execution of the flow is getting slow, i.e. sometimes more than 20 seconds between two commands

- the mute key is recognized only several seconds - sometimes more than 20 - after it is pressed

- the PTT button is not working any more for extended periods of time

- the voice recognition rate gets significantly worse up to a point where MCE understands all kinds of nonsense but not the actual command any more

- exiting MCE does not properly close the program. When restarting (after waiting a significant amount of time) it says that MCE is still running and I have to use the Kill-MCE-App.

 

Factors that contribute to or worsen the phenomenon seem to be:

- having the FO talk to PF3-ATC while or immediately before or after the execution of a flow

- giving a command while executing a flow

- giving several commands in very short sequence, in particular if it happens unintentionally when the microphone picks up some noises

- pausing the sim while a flow is being executed

- giving a command (also by the microphone picking up a noise) while the sim is paused

- using accelerated sim rate.

 

All these factors seem to have a persistent impact on the performance of MCE, cumulating over time. On many flights that leads to MCE being almost unusable when I reach the approach phase (whereas everything worked perfectly when starting the session).

Closing (and using the Kill-MCE-App when necessary) and restarting MCE (with the sim session continuing) always cures the problem and I can start again with a fresh and fast MCE.

 

It kind off reminds me of the OOM-errors we once had with the 32-bit sims. Is it possible that MCE somehow cumulates buffered data and gets overloaded at some point?

 

Nevertheless to come to the point of the topic title:

Until you find a way to further track down this problem it would be of great help if MCE could easily be reset resp. restarted from the UI or the right click menu (also automatically running the KILL-MCE-App if necessary). Is it possible to add such a function? 

Thanks!

We'll see if an option for reset can be implemented.

Definitely not a OOM error.

As MCE (mce.exe) runs as an external process to the sim, it has a whole 4GB VAS for itself and it hardly needs a quarter of that.

The issue is probably linked to "Multithreading". It's a hard problem even for the most experienced C++ programmers.

Because things don't happen in a controlled sequence and there is the need to disable Fo commands while you're talking to ATC and re-enable them when you release, there are small vulnerabilities, like a specific background thread getting stuck waiting for specific conditions to happen (that kind of thing prevents an app shutting down properly).

For instance a command part of the flow would need to wait while PTT is down as none of the flows commands would be recognized when commands are submitted to speech engine and all FO commands are disabled.

This is why it's not a good idea to run speech engine inside the simulator process via a gauge.

Would appreciate if you could perform a similar flight and leave out ATC completely for that session.

This would narrow down the issue (PTT or threads monitoring and interacting with PF3 ATC)

 

Share this post


Link to post
Share on other sites
10 hours ago, FS++ said:

Would appreciate if you could perform a similar flight and leave out ATC completely for that session.

This would narrow down the issue (PTT or threads monitoring and interacting with PF3 ATC)

 

I will do a couple of flights and report back.

Share this post


Link to post
Share on other sites
On 9/3/2019 at 9:36 PM, RALF9636 said:

I will do a couple of flights and report back.

May not be necessary as we found what could be the root cause.

A new build should be posted tomorrow and we'll take it from there.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Just to let you know I made two flights without PF3 and the ATC option in MCE turned off. On both flights the problem occured again.

 

Share this post


Link to post
Share on other sites
16 hours ago, RALF9636 said:

Just to let you know I made two flights without PF3 and the ATC option in MCE turned off. On both flights the problem occured again.

 

Thanks.

New package now ready for download

Share this post


Link to post
Share on other sites
13 hours ago, RALF9636 said:

Unfortunately the new version has not changed anything for me.

 

Are you using all MCE features, including "call-outs and monitoring" or did you disable some?

Share this post


Link to post
Share on other sites
30 minutes ago, FS++ said:

Are you using all MCE features, including "call-outs and monitoring" or did you disable some?

All features are active.

Should I try to deactivate callouts and monitoring to narrow down the issue?

Share this post


Link to post
Share on other sites
5 hours ago, RALF9636 said:

All features are active.

Should I try to deactivate callouts and monitoring to narrow down the issue?

No, just wanted to know whether more testing should be done under a specific usage scenario.

Based on the other thread, it could be that your microphone is overloading speech engine and possibly causing latency.

If you have a USB headset and didn't unplug it for a long while, you may want to do so, touch the connector, wait a couple of minutes, then re-plug it.

 

 

Share this post


Link to post
Share on other sites

I recalibrated the microphone (not USB) and also did the voice recognition training again.

MCE picking up noise as a command seems to be less frequent now, but unfortunately problem itself has not changed at all.

 

 

Share this post


Link to post
Share on other sites
On 9/9/2019 at 9:30 PM, RALF9636 said:

I recalibrated the microphone (not USB) and also did the voice recognition training again.

MCE picking up noise as a command seems to be less frequent now, but unfortunately problem itself has not changed at all.

 

 

Should notice improvement in V2.8.0.4, just uploaded.

 

Share this post


Link to post
Share on other sites

You are on to something here!

There is no lag any more in the execution of the flow. But now some flow items are skipped. MCE sometimes proceeds directly to the completed-message but does not execute some of the commands in-between.

It looks as though, where in previous versions there was a lag before executing a command of the flow, now this command is skipped instead.

This only happens when the microphone is open. When I press the mute-key (numlock) immediately after saying the name of the flow, everything works perfectly, nothing skipped, no lags (so far). Pressing the mute-key also helped against the lags in previous versions. 

So I guess you have found the cause of the issue, but not yet completely solved it ;-).

Edited by RALF9636

Share this post


Link to post
Share on other sites
19 hours ago, RALF9636 said:

You are on to something here!

There is no lag any more in the execution of the flow. But now some flow items are skipped. MCE sometimes proceeds directly to the completed-message but does not execute some of the commands in-between.

It looks as though, where in previous versions there was a lag before executing a command of the flow, now this command is skipped instead.

This only happens when the microphone is open. When I press the mute-key (numlock) immediately after saying the name of the flow, everything works perfectly, nothing skipped, no lags (so far). Pressing the mute-key also helped against the lags in previous versions. 

So I guess you have found the cause of the issue, but not yet completely solved it ;-).

OK, good.

Next update should settle it for good.

Meanwhile, try stress testing it by asking co-pilot questions while he's performing the flow or throwing direct commands to flip switches or dial values.

Make sure when a flow is in progress, holding PTT down puts it on hold and it resumes about 5 seconds after you release it.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...