Data Usage Tracker 3.2.1

The collector's hourly snapshot moves off the system drive.

Correction (2 October 2026). These notes first said this change fixes Fast Startup shutdowns that stall with the fans running. It does not. Measured since, those stalls came from the system SSD writing the hibernation image slowly (11-50 MB/s instead of ~700 MB/s) when its write cache was full, before and after this change alike. If your shutdowns do that, Windows records it as HiberWriteDuration in the Power-Troubleshooter event at the next start; turning off Fast Startup or freeing space on the system drive is what helps.

Changed

• The snapshot is off the system drive. The elevated snapshot task kept its ~99 MB copy of the SRUM database, its deployed script and its status file in %ProgramData%\DataUsageTracker, so every hourly collection wrote and replaced 99 MB on C:, about 2.4 GB a day on the drive Windows runs from.

  register-task.ps1 now deploys to DataUsageTracker-snapshot at the root of your database's drive when that drive is NTFS (-DeployRoot picks another folder), and keeps %ProgramData%\DataUsageTracker otherwise. The folder is still created admin-only in one step and checked on every run; the collector finds it through the snapshot task, and re-registering removes the old one. Your scratchDir was already yours to place, and stays where config\collector.json puts it.

Fixed

• Light theme: hovered rows, the band behind a hovered bar, and never-collected heat-map days are now visible on white.

Upgrading

git pull, npm ci, npm run build, restart the dashboard, then re-run scripts\register-task.ps1 from an Administrator PowerShell. That is what moves the snapshot folder; until you do, the collector keeps using the old one and logs that the deployed script differs from the repo. The Android app is unchanged: keep 1.3 from the 3.1.2 release.

Prefer a native Windows app over the dashboard? Data Usage 0.2.1 makes the same change. Run one collector or the other, not both: each takes its own hourly snapshot.