Abnormal CPU usage

[denist]

I am new to Voxcommando and I am evaluating it to use it fully in my system. It seem to work pretty good, but I am founding that VoxcommandoSP.exe starts using between 50 to 60% CPU for no reason at all after about 5h of inactivity and I have to close it and restart it to fix this.
This happens indipendently in ON and in Stanby mode.
I am using v.2.2.4.0 and trying also the beta 2.2.4.1.
Plugins MQTT and Sonos.

[jitterjames]

Sorry to hear about that unusual behaviour.  I think it may be quite difficult to pin down the cause.  The simplest solution might just be to have VC restart itself every 3 hours.  I guess it depends on how predictable the timing is.  If you are unsure how to do this I can send you XML for a command.

In order to try to find the problem, you could try to disable the plugins, one at a time and see if it makes any difference.  Then at least we would know if one of the plugins is responsible.  I run Sonos plugin 24 hours a day and I don't normally have any problems.

I have seen the CPU spike before and restarting VC fixed the problem, but I have not seen that activity for many months (I can't remember the last time but it was a long time ago) and I run VoxCommando on my HTPC all the time that the PC is awake, which is most of the day and the evening.

You can try to enable logging and send me a complete log, telling me at what time the CPU activity goes up, but I suspect that this will probably not show us anything useful.

[denist]

Thanks for the response.
The issue seems to be related to the MQTT plugin (2.0.2.0), since I do not have this problem when disabling this plugin.
Unfortunately MQTT is an essential part of my project, so I will try to find out how to restart VoxCommando every 2 hrs or so and reconnect to the broker.

[jitterjames]

It's not possible to automatically restart the trial version of VoxCommando using VC actions for obvious reasons.  You would need to either purchase a license or use some other external method to restart VoxCommando.  When VC is activated it's very easy to get it to restart itself every 2 hours.

But now that you've narrowed it down to MQTT I can take a closer look to see if there is anything I can find to fix in the plugin.

If you notice any patterns please let me know.   For example, does the CPU go up after an MQTT message has been received?  Does that message trigger an event that causes a particular command to run, and what is the command?  Stuff like that.  Anything else that happens that might be related.

[denist]

Thanks for your info and support. 
I am looking into restarting VC via the standard Windows activity planner and it kind of works. Of course this is not a clean method and should be temporary just for evaluation purposes.
The only issue is that VC does not connect by itself to the MQTT broker when VC restarts: I tried setting MQTT.Connect at VC.Loaded event, but it is not working. It seem that MQTT.Connect works only if there already was a first manual connection. So just for re-connection scopes. In other words, the MQTT Status can pass from "disconnected" to "connected" via MQTT.Connect but not from "null" to "connected".
Regarding the MQTT activities I have with VC, at this time they are very limited. I do not subscribe to topics via VC since it does not need to receive any data. It does need to publish data thou, but only at voice command. Hence, actually the MQTT plugin shall do perfectly nothing for 99% of the time. Still the CUP goes up for apparently no trigger at all.

[jitterjames]

The only issue is that VC does not connect by itself to the MQTT broker when VC restarts: I tried setting MQTT.Connect at VC.Loaded event, but it is not working. It seem that MQTT.Connect works only if there already was a first manual connection. So just for re-connection scopes. In other words, the MQTT Status can pass from "disconnected" to "connected" via MQTT.Connect but not from "null" to "connected".

Are you sure about this?  What is the error that is generated when you try to connect and it fails?  You can find the error in the log or in the history window by hovering the mouse over the error generated action. (The history window must be focused or hovering won't work).

If this is true then it should be something I can fix but I thought VC automatically connected to the broker on startup if the MQTT plugin was enabled and properly configured.  I will look into it.

[denist]

Hi, I am attaching here a couple of screenshots. Maybe I am the one doing something wrong, but actually the MQTT.connect does work if called after a first manual connection and disconnection in the same VC session. The only thing I see different is that, at VC start, the status is blank while otherwise it says "disconnected".

[jitterjames]

OK.  I figured out the problem with connection.  I assume it will be easy to fix but I did not look at the code yet.

The plugin was originally created specifically to work with Happy Bubbles Bluetooth beacons.  I guess I never tested the MQTT function with the Happy Bubble feature disabled.

For a quick fix I think you can just enable the Happy Bubbles feature on the 2nd tab of the plugin settings which should allow it to connect automatically on startup.  But I will release a replacement plugin DLL with a fix ASAP.

Also, I still don't know what is causing your CPU usage (I can't seem to recreate this problem yet) but you could try to remain disconnected from the broker since you don't listen to messages from it.  When you want to send a message, first connect, then publish, and then disconnect again all in the same command.  Maybe it will help.

[jitterjames]

Here is an updated DLL and XML file for the MQTT plugin.

Put them both in the ".\VoxCommando\plugins\MQTT" folder replacing the original files.

Be sure to unblock the .dll file:  http://voxcommando.com/mediawiki/index.php?title=Unblock_DLL

The XML file is required in order to expose the disconnect action, which was already implemented but not in the XML for some reason so the action did not appear in the command editor.

[denist]

Thank you, I will try that.
For information, the CPU goes high even when MQTT broker is not/has never connected.

[denist]

Latest news:
- your fix files work for connecting MQTT broker at VC start (MQTT.Connect at VC.Loaded event). 
- today I left the PC on with the MQTT plugin disabled and, differently from the other day, I found it with CPU activity 40-60% anyway. So at this point, it may not depend from MQTT. 

I will see how it goes on with restarting VC every 2h.
Thanks again for your kind and quick support.