Jump to content

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

A few more flights and still no lags any more. Stress testing as you described is hard to do though because flow items are skipped so that the flow is completed before I could issue many commands.

For now I press numlock immediately after starting the flow and everything works perfectly.

Looking forward to the next version when pressing numlock won't be necessary to have everything work perfectly 😉

 

Edited by RALF9636

Share this post


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

A few more flights and still no lags any more. Stress testing as you described is hard to do though because flow items are skipped so that the flow is completed before I could issue many commands.

For now I press numlock immediately after starting the flow and everything works perfectly.

Looking forward to the next version when pressing numlock won't be necessary to have everything work perfectly 😉

 

Latest is ready for download and should settle things.

 

Share this post


Link to post
Share on other sites

I hate to say it, but the lags returned with 2.8.0.5.

I reinstalled 2.8.0.4 and compared the time it took to completely execute a flow that always seemed to be prone to the problem. Whereas in 2.8.0.4 it took about five seconds (no skipped items in my test) it was around thirty seconds in 2.8.0.5 (like in the versions before 2.8.0.4). And pressing the mutekey did not help to speed things up in 2.8.0.5.

 

Another observation that probably is unrelated but notable anyway: There seems to be an issue with the uninstallers. Both uninstalling 2.8.0.4 and 2.8.0.5 (and I think I first noticed that already when uninstalling 2.8.0.3) there was a long pause for about five minutes at around 10 % of the uninstalling progress, before the uninstaller then quickly finished. That seems to be unusual.

 

Share this post


Link to post
Share on other sites
25 minutes ago, RALF9636 said:

I hate to say it, but the lags returned with 2.8.0.5.

I reinstalled 2.8.0.4 and compared the time it took to completely execute a flow that always seemed to be prone to the problem. Whereas in 2.8.0.4 it took about five seconds (no skipped items in my test) it was around thirty seconds in 2.8.0.5 (like in the versions before 2.8.0.4). And pressing the mutekey did not help to speed things up in 2.8.0.5.

 

Another observation that probably is unrelated but notable anyway: There seems to be an issue with the uninstallers. Both uninstalling 2.8.0.4 and 2.8.0.5 (and I think I first noticed that already when uninstalling 2.8.0.3) there was a long pause for about five minutes at around 10 % of the uninstalling progress, before the uninstaller then quickly finished. That seems to be unusual.

 

We use Microsoft installer-uninstaller technology. Nothing we can do about that. It's completely managed by Microsoft.

I believe at some point UAC should pop-up and it doesn't always kick in in a timely manner (shows up on task bar but no fading Window screen immediately as you would expect).

With regards the latest changes made to MCE, from now on, do not use the Mute button or key key as a means to speed up the flow.

It works OK now. No skipping and the execution speed is improved. MCE enforces a minimum delay of 2.5 seconds between 2 consecutive commands, even if no pause is inserted in the flow.

As long as "mce.exe" is V2.8.0.5 you're on the latest.

Unlike with previous iterations, this one should make a real difference. Try again please.

Would appreciate if others chime in to provide more feedback, as it's hard to work out what needs to be changed.

 

Share this post


Link to post
Share on other sites

I confirm I am on V2.8.0.5 now and do not use the mute key.

In V2.8.0.4 there was no 2.5 seconds delay between two commands. It was less than a second. So that easily explains why the execution of the flow is slower in 2.8.0.5.

The deterioration of the performance over time and the temporary unresponsiveness seems not to occur anymore in 2.8.0.5.

But there are delays much longer than 2.5 seconds between two commands, in particular if these are voxkey commands (and I use lots of them).

In this context I noticed that the "reply" is not spoken out if the first command in the script is a voxkey command. When I add "pause=2" before the first command the reply is spoken out; also the reply is spoken out when a "normal" command is the first command. Maybe this is related to the delayed execution of the voxscript commands.

In V2.8.0.4 the commands were executed with less than a second in-between, also with voxkey commands. There was just the problem that some commands were skipped which could be prevented by pressing the mute key. So MCE basically is able to execute the commands in short sequence.

So why are the delays happening again in 2.8.0.5?

Isn't it possible to do some kind of logging to find out what is happening on my system? Apparently this is not a common issue for MCE users so it must be related to my way of using MCE: FSLA320 (involving 2D panels, these commands also seem to be prone to delays), PF3 interaction, around 30  - some very short, others quite long - voxscripts (always verbose=0) I run during a normal flight, lots of my own voxkey commands integrated into the voxscripts.

 

 

Edited by RALF9636

Share this post


Link to post
Share on other sites
46 minutes ago, RALF9636 said:

I confirm I am on V2.8.0.5 now and do not use the mute key.

In V2.8.0.4 there was no 2.5 seconds delay between two commands. It was less than a second. So that easily explains why the execution of the flow is slower in 2.8.0.5.

The deterioration of the performance over time and the temporary unresponsiveness seems not to occur anymore in 2.8.0.5.

But there are delays much longer than 2.5 seconds between two commands, in particular if these are voxkey commands (and I use lots of them).

In this context I noticed that the "reply" is not spoken out if the first command in the script is a voxkey command. When I add "pause=2" before the first command the reply is spoken out; also the reply is spoken out when a "normal" command is the first command. Maybe this is related to the delayed execution of the voxscript commands.

In V2.8.0.4 the commands were executed with less than a second in-between, also with voxkey commands. There was just the problem that some commands were skipped which could be prevented by pressing the mute key. So MCE basically is able to execute the commands in short sequence.

So why are the delays happening again in 2.8.0.5?

Isn't it possible to do some kind of logging to find out what is happening on my system? Apparently this is not a common issue for MCE users so it must be related to my way of using MCE: FSLA320 (involving 2D panels, these commands also seem to be prone to delays), PF3 interaction, around 30  - some very short, others quite long - voxscripts (always verbose=0) I run during a normal flight, lots of my own voxkey commands integrated into the voxscripts.

 

 

Possibly related to Voxkey commands as I didn't test that scenario with latest changes.

The 2.5 seconds delay relates to the absolute minimum delay between 2 commands sent to speech engine to simulate spoken command.

It's actually a bit more complicated than that as you don't just simulate a spoken command, wait for 2.5 sec and send next one.

You have to wait for speech engine to recognize previous one, process it  as if you gave the command directly (which could take up to 10 seconds), then wait 2.5 for safety and send the next one.

2.5 sec is arbitrary, and could eventually be lowered. It hasn't changed for the last 3 years or so.

its main purpose is to ensure Fo can properly identify which command is spoken directly and which one is part of a flow.

For instance, if a flow is silent, he has to keep quiet, while maintaining the ability to be vocal when you eventually ask him a question, or command him to do something else while a flow is in progress.

In verbose mode, you may not even notice the delay as the Fo could take 3 seconds or more acknowledging the first command.

There are exceptions, like a command for flight control check which allows for up to 30 seconds to be completed before the next one is sent to the speech engine.

Try it with PMDG 737 NGX, T7 or B747 or some aircraft with which MCE doesn't need to pop-up 2D panels  if you can.

Thank you once again for forcing a re-think of this particular feature.

 

Share this post


Link to post
Share on other sites

Thanks for the insight to the reasoning for the 2.5 sec delay. Apparently you experimented without that in 2.8.0.4. which led to that some commands were skipped because it was too fast to simulate the spoken command. And by pressing the mutekey that was not a problem because that way simulating a spoken command was not necessary. Just wild guessing... 🙂

 

But I wonder, isn't it possible to take the scripted commands as such - without the detour of simulating a spoken command? It seems to me 2.8.0.4 did something like that. I understand that then it probably wouldn't be possible to give additional verbal commands while the scripted commands are executed, but I would be fine with that. Many of my longer scripts include some pauses so I could give necessary commands then. And the shorter scripts would be completed within a few seconds, so it wouldn't be a problem.

Maybe optional for every script, like "verbose=1", something like "scripted execution=1".

 

Apart from that I would appreciate if you test some voxkey commands and make them as fast as the other commands.

 

I almost exclusively fly the FSL A320 these days and the only other Airliner I sometimes use is the Q400 which also involves 2D panels.

 

Edited by RALF9636

Share this post


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

Thanks for the insight to the reasoning for the 2.5 sec delay. Apparently you experimented without that in 2.8.0.4. which led to that some commands were skipped because it was too fast to simulate the spoken command. And by pressing the mutekey that was not a problem because that way simulating a spoken command was not necessary. Just wild guessing... 🙂

 

But I wonder, isn't it possible to take the scripted commands as such - without the detour of simulating a spoken command? It seems to me 2.8.0.4 did something like that. I understand that then it probably wouldn't be possible to give additional verbal commands while the scripted commands are executed, but I would be fine with that. Many of my longer scripts include some pauses so I could give necessary commands then. And the shorter scripts would be completed within a few seconds, so it wouldn't be a problem.

Maybe optional for every script, like "verbose=1", something like "scripted execution=1".

 

There is a reason for that.

If you handle scripted flows commands directly, you'll have to do a lot of text parsing and eventually tell users they have to write commands in this exact manner and you could mix-up commands that are very similar, never mid the fact you wouldn't allow any variations or let users write custom commands acting as aliases for existing commands, for natural speech.

You also need to have duplicate code paths doing the same thing.

Speech engine returns what speech was recognized, but more importantly tells you this speech matches rule XX MCE has defined.

You then know which item the command relates to without needing to wade through all the possible speech variations.

There is still room for improvement.

V2.8.0.4 was flawed because it favored speed over reliability.

It would typically send commands and if for some reason a simulated command takes much longer time than expected, it would eventually skip all the next commands.

You run the same flow at a different time and it may go without a hitch.

V2.8.0.5 is robust now. Just need to see how far we can push it.

If you go to the <Edit script commands" panel in the UI and press "Test" for each individual command, you'll notice there is almost no delay. Whereas before, it could take 1 to 3 seconds (and sometimes more) for the command to be acknowledged by speech engine.

 

 

Share this post


Link to post
Share on other sites

Ok, I'm starting to see the genius behind all that... 😉

So I guess when you manage to execute the voxscript commands and those opening a 2D panel at the same speed as the others, everything will be fine.

Edited by RALF9636

Share this post


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

Ok, I'm starting to see the genius behind all that... 😉

So I guess when you manage to execute the voxscript commands and those opening a 2D panel at the same speed as the others, everything will be fine.

The automatic opening/closing of 2D panels happens in the "mcfslA3X.dll" running inside Prepar3D.exe process.

It adds a level of complexity as MCE needs to give it enough time before it assumes item has been clicked.

Luckily, most items are handled directly in VC and the few that require 2D panel are only touched at the beginning (preparation) of the end of flight.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...