Planefinder Client high CPU usage


New Member
I've noticed recently that my mini-PC (Windows 10 64 bit) on which Planefinder is installed was working a bit harder than usual. I found today that it was using between 25 and 35% of CPU time. I deleted and re-installed and it then sat at barely 1 or 2% CPU usage during the time I watched usage in task manager. This evening it is once again running back up at 25+% .

I'm unsure how long this has been going on, but I have noticed the fan kicking in much more. Does anyone have any suggestions as to what is happening?

EDIT: it appears to take about an hour after a restart to go from 1% to the 25+%
Last edited:

The PFClient program is usually very resource efficient, with a small footprint on the system.

I guess there might be a problem with the mini PC. The general advice is worth following.

- There may also be a maintenance or indexing process in the background, typical of increased CPU usage during the idle period. This is normal.
(not the case if PFClien's CPU usage is so high alone)
- Look for malware - use Malwarebytes' Antimalware or similar, or the built-in protection can help, too)
- Keep Windows up to date and factory drivers installed, not just Microsoft's own drivers.
- Check system integrity. Run "cmd" as an administrator and use the "sfc /scannow" command.

Good luck
Last edited:
Hi Janos,

Thanks for the reply. Confirming that it is only the PF client that is the issue, currently it is showing at 27% CPU and 'Very High' power in task manager. Planeplotter and VRS are also running, but for a total of less than 3% CPU. Running sfc picked up and fixed a corrupt Microsoft.Net framework file, but that was all.
If you use third party antivirus and firewall combo, try to switch it off for a short time. Some of them can slow down even a really good machine.
You will not be without defence, since built-in security modules will come up to work right then.

PFClient works on the fly, without touching the storage. It handles text format and network only... It creates some log about transactions, nothing else.

If the slowdown is caused by protection software, add PFClient software to the exceptions. (mark as trusted)

After the sfc fix, a restart should come, even if it was not required at the end of the process...

Also check debug.log file in "C:\Plane Finder ADS-B Client" folder.
Last edited:
No third party resident protection. Nothing unexpected in the PF log files. It is only showing as using CPU time and about 3Mb of RAM in task manager. I'll do another restart and watch the behaviour.
Recent PFClient version is 4.2.70
Check it, pls

If the error still occurs, you may want to install the motherboard drivers. Mini PCs use mobile processors and / or special power environments. General divers do not always work properly.
Last edited:
Yes, that was the first thing I checked. 30 minutes so far and no problem. When the pc is working hard it also resonates with my tinnutis, so I should know as soon as it happens :)

EDIT: Almost an hour and OK. I haven't a clue if the .net framework file corruption is relevant, but the second restart may have fixed it. I will have to leave it now and check later.
Last edited:
Thats a bit over 1.5 hours and its still behaving. Thanks for all your input. All I have to do now is get VRS going again, but the logs suggest that is an internet server download problem.
your welcome

My feed to PF seems to be ok - no connection problems.
Check your PF settings, mainly if you reinstalled it.
VRS works as a local monitor here and I use it also for rebroadcasting towards the client. Download side is for getting pictures only. Ok, perhaps refreshing the database if you have the database writer plugin...
Last edited:
VRS is up and running now as well, it my have been the tile provider off line. I only use it for re-broadcast anyway.
PF started gobbling up resources again a few minutes ago. Its been fine since yesterday. 'Restart Client' didn't fix it, but an exit and start did....for now.
PF started gobbling up resources again a few minutes ago. Its been fine since yesterday. 'Restart Client' didn't fix it, but an exit and start did....for now.
Try to find a driver update for your system (e.g. inf update for Intel ) and for the network chip as well. If your mini-PC is not custom-made, try the manufacturer's version - even if it's older.
For a self-assembled device, check the motherboard manufacturer's website for resources.
Last edited:
for example:
The Realtek controller defaults to 4 queues which increases core and interrupt activity the most. Lower this to two queues and you should possibly see the reduction you want. But of course, it can be the driver and how all is handled, or an issue elsewhere. Give the two queues change a try first.
/ RSS settings in special (advanced) part of the Network adapter properties /

You can also have a try on changing speed settings from auto-negotiation to 100 Mbps full duplex

...I have no additional ideas right now.
Last edited:
Its certainly a bit of a mystery. I've reinstalled the lan and chip drivers, although they appeared to be the latest versions already. What puzzles the most is why only this one application (PF) and why so long a delay before it 'takes off'? Nothing else on the system is misbehaving. Most of the time PF CPU usage shows 0 CPU and 2Mb memory, while the total system CPU is less than 5%.
The phenomenon also occurs on servers, of course on a larger scale but also under completely normal load. As I mentioned, queuing and handling interruptions is the source of the problem. The effects of negligible errors accumulate over the long process and can even cause a "fatal exception."
You may not have another process - similar to PF's nonstop thread - so, the high cpu load had not occured (yet). Probably, there was a system update, thus the phenomenon appears in "new" circumstances only.

I hope, the "reinstalled" drivers mean the ones from the hardware manufacturer.
Last edited:
Any news? I hope all is ok.
All going well until about 10 minutes ago, when it started harmonizing with my tinnitus again.... yep, 28% CPU. Stopped and restarted PF and fine once again. More than 48 hours without an issue this time. No other processes having issues, just PF.