Closed MalicT closed 5 years ago
Please have a look at #1238.
Disabling shipmonitor plugin in EDDI seems to remedy CPU usage with VoiceAttack.
With this off 3.3.7-b1 seems to bring VA use back to normal 0.1-0.2%
Is the ship monitor needed to get my current ship stats because otherwise this breaks a lot of the info commands in my VA profile?
I'm running EDDI and VA as I write this and CPU utilization (after 'log load') seldom peaks above 2%.
Parsing the journal log at startup, to catch any missing events (log load), will utilize a significant chunk of CPU utilization (mine peaks at 30-ish %) at startup, but it settles down with 15-20 sec.
Recommend you look at your verbose eddi.log and report back on any errors/exceptions you see.
Mine jumps to 20% on initial VA startup and over the course of maybe 10 mins it will rise up to 80%... at this point the CPU is saturated and it is fighting with all other programs and the computer starts to chug along and become unresponsive.
We're sorry to hear that your CPU utilization is still so high. We were able to resolve the issue we found, but since your CPU utilization is still high there may be another issue we need to resolve. We need more information to figure out how to replicate and diagnose this issue.
%appdata%/EDDI
)? (Verbose logs preferred)please provide a copy of your latest log files (located at %appdata%/EDDI)? (Verbose logs preferred)
Non verbose. The verbose logs are all unuploadable for me as they rise in size extremely quickly and end up being over 50mb in about 5 seconds(left alone for the minute it takes the CPU usage to settle back down it was almost 400mb which would take me about an hour to upload).
Are you logged into the Frontier API? If so, does keeping the ship monitor enabled, logging out of the Frontier API, and reopening VoiceAttack result in prolonged (more than a few minutes) elevated CPU utilization?
Not logging into the API only changes the first few startups before I have switched to a few ships. After that it's the same with or without the API(Deleting my shipmonitor.json totally fixes this problem until it's got more than two or three ships in it and then it starts up again).
Do you keep your ships at a small set of locations or are they scattered to many stations throughout populated space?
46 out of my 48 stored ships are in two stations around Earth in Sol with one at an outpost on Mercury and the last in another system. Just guessing but it seems to be more to do with the number of ships not the locations. I tried playing around with removing all but my active ship from the shipmonitor.json and then adding each ship back in one at a time. Every ship I added back in added a few more seconds of high CPU usage before it settled back down but adding back only one per station didn't result in a longer spike than just having 4 ships from the same station.
Do you see the CPU go up if the ship monitor is enabled but not selected when EDDI starts? Is it only when launching EDDI with the ship monitor as the active tab?
Either way and only running through Voice Attack.
are you observing any other unexpected behaviors?
Just this.
Consolidating with #1238.
Just updated to VA v.17.3.8 and boom... the CPU shoots up. I backedup my profile. Deleted it from VA. Uninstalled the VA. CCleaned. Restarted. Reinstalled, imported the profile back. No change. CPU screams high. Plz check pic's. Is this a VA issue or EDDI issue,- or both?
See #1238 for further updates on this issue please.
EDDI version in which issue found
3.3.7-b1
Steps to reproduce
Start VA with EDDI 3.3.7-b1
Expected
VA to use 0.1-0.2% of CPU
Observed
VA starts using 25% on startup and raises to 50% in matter of seconds, and then slows computer to a crawl
Investigation
VA, turn off all plugins, uses 0.1-0.2% of CPU
Open plugin manager, only turn on EDDI 3.3.7-b1, restart VA
After restarting VA, VA immediately uses 25% of CPU, when Elite starts, goes up to 50% and then over time creeps up to 80%. It might be trying to use more, but at this point my CPU is being saturated, and it is a Intel Core i7 6900K
3.3.5 is when this behavior started, 3.3.6 is also displaying this.
Am returning to 3.3.4 until this is fixed as it is the last good version that does not have the looping code that was said to be fixed in the last report I did. https://github.com/EDCD/EDDI/issues/1194
Correspondence had said it was marked as fixed, but was not:
https://i.imgur.com/RMllXRJ.png
https://i.imgur.com/jdw1oCG.png