I've seen this reported before, but not narrowed down to Windows 7?

This is new behavior with the new v9.90+ client, right? Not with the old one?

v9.90 moved to using a "wrapper"... where there's BOINC-provided wrapper program that runs a a generic, unmodified binary to process the code. I'd say the majority of BOINC projects run the wrapper for their clients, we were a bit of an odd duck because we modified our client to use the BOINC API directly. However, there were issues with this and pytorch (both wanted to use the SIGALRM posix signal), so we moved off of that for the latest client. It's certainly possible that the wrapper is, sometimes, on windows, not cleaning up all its child threads. But since we didn't write the wrapper (literally we're using the binary from https://boinc.berkeley.edu/trac/wiki/WrapperApp), I think this might be worth opening a bug report on the main BOINC github repo.

:(

Minor update:

I'll try moving over the old credit later this week when (hopefully) we'll have some scheduled downtime to move to the new server. For those who don't have badges yet, give me another week. That'll also coincide with the early adopter badge. I can practice on my own account first :)

Are you going to export to the BOINC Signature site. https://signature.statseb.fr/

It doesn't work that way. It's up to the signature sites to import the stats from here. This question needs to be asked at the stats sites. (It already has been.)

Hmm.. Each badge entry in the DB has an ID, a name, and a description. I updated the description, not realizing the UI (at least on this site) is only showing the name as alt-text in the image. Will fix. Thanks.

And it certainly will be easier to do before we add a new app! The problem is that credit is now kept in two places (the original user table, and a special new user_app table). RAC is also now calculated in two places as well. How would just adding the old credit to the new table effect the per-app RAC calculation? If one day 3 months worth of credit just showed up, that would be way off. So definitely doable, and *may* be as simple as "per_app_total += global_total - per_app_total", but we're not going to blindly go in there and do that without assuring ourselves it doesn't break something.

We know it's not optimal to have the milestone badges not include the total credit accumulated before we flipped the switch on per-app credit. I suppose it's something we should have been doing from the start (I was sad the server didn't convert it all itself when we turned on the feature).

Fixing that, however, will require (carefully!) hand-editing the database to re-assign the old credit, and also diving into the server code to understand exactly how per-app credit works internally so we know how to update the old credit appropriately.

So we've made the decision, for now at least, to only include credit earned from this point onward. To help ameliorate that somewhat, everyone with credit will, of course, qualify for the Early Adopter badge, and the descriptions for the milestone badges have been updated to explicitly say "...since October 2020" so it's obvious its only counting credit since today. We hope that's an acceptable solution, at least for the time being. We may revisit this in the future (we can always go back later), but for now we felt it was more important to get milestone badges out there.