Client doesn't always reset unpulsed application data on pulse

I’ve noticed this issue from version 3.4 and it happens on 3.5 as well.
After I pulse, sometimes the unpulsed application data for some applications (but not all) doesn’t reset and it sticks around on subsequent pulses, inflating the application key/click counts.
In my last 4 pulses the application data for Quaver didn’t reset and cumulated/duplicated from one pulse to another.

Pulse 1:
The application data key count doesn’t seem to add up perfectly to the pulse key count but that’s an older bug where some applications don’t get tracked. However the application data is displayed fine for Quaver as that was the main source of key presses during this pulse.

Pulse 2:
As you can see, the application data for Quaver hasn’t reset and the key count is higher than that of the pulse itself. Also I haven’t used VirtualBox for 4 hours and 33k keys that day, so it seems to have duplicated from past usages.

Pulse 3:
Again, Quaver has duplicated the keys/uptime from the past pulses, showing a higher key count than the pulse itself, and VirtualBox has duplicated its stats too, because I’ve only used it for a few minutes that day.

Pulse 4:
The last pulse which just reinforces the prior statements, the Quaver key count in this pulse is 229,512 , which is identical to the 3rd pulse, because I haven’t played Quaver at all during the duration of this pulse.

This issue wasn’t occurring on Whatpulse 3.3 and earlier. I switched back to 3.3 for a while and I checked the pulses and it wasn’t occurring. I think I’m going to roll back until this is fixed because it’s ruining my application stats.

Windows 10 x64 bit

Hope this get fixed fast as possible so that it doesn’t become a huge problem.


This doesn’t have much to do with the client - nothing has changed there in a while. It’s more around the website and the time it takes to respond back to the client during the pulse. There’s been some growth and the pulse process handles a lot these days. I’ve started moving tasks to background data processing this week and see the response times reducing for the pulses (which is a good thing). I think that helps, but I’ll also add some extra sanity checks in the client when it pulses for 3.7.