It seems to be inherent in any drive that is not nvme. All my nvme's display the entire data your application requests, with only two being Samsung. All others that are not nvme do not. The Crucial SSD is not alone non-nvme SSD's that do the exact same thing on my systems and do not display all data. So it may well be in all non-nvme's that they made it unavailable? I do not know. It also would not surprise me if in all non-nvme's, it is by design.

Just a heads-up: I noticed here that temps for a couple of drives got "stuck" apparently after resuming from sleep/hibernate.

Could have something to do with the code I added to detect "hung" drives so this do not get called again and temp for other drives can still be obtained (at least that part worked as expected).

So, if you have other software capable of reading drive temps or the temp of one of your drives does not change for a long time, you might want to compare. Only thing that fixes it is restarting the Winstep Service.

Anyway, I've changed the code so that if a drive gets marked as "do not touch" the temps returned become N/A instead of some fixed stale value. Also adding debug info to try and figure out what is happening as well making the application reset the service drive list after returning from hibernation/sleep (which should fix any "stuck temps" issue without having to actually restart the service).

Do the presets get stored on a per theme basis, or system wide? I confess that I haven't changed themes to verify. If it were system wide then a user may want to group presets to match a theme which is when sorting would be useful.


Is this after your fixes? As I can assure you that the file was not being replaced when I was testing.

Another thing that I noticed is that the drop down box does not resize (probably sensibly) to match the length of the preset name string, but there is no limit on the name size that can be entered. I suggest that the name size be limited to the width of the box - otherwise you could effectively be in the same position as duplicating entries from a user visibility perspective.

System wide. They are user settings, and currently they are only being stored in the Windows Registry, which means they are not (yet) being saved even if you back up your settings.

[

I can make the drop down part resize to the widest preset name OR limit the number of characters users can type in (or both). Will probably opt for the former.

To be clear, unlike the Workshelf which stores per theme, you are saying that when you change the drive module and go back to a an earlier theme where I may have changed it, the drives will revert back to default like they are currently? did I get that correctly?

I hope you intend to do the same as Workshelf and store per theme at some point.

In which case I would re-iterate that ordering may be useful, particularly if a user wants to preface the preset name with a theme name say.


I would do both then, as you could make some long strings!

May I make a suggestion about the placement of the Icon Primary/Secondary Metric text for the Disk Meter Icon's.

The placement for the Drive style icon is fine, but the text placement on the Ring Chart Icon, is a little too high. It slightly overlaps the icon itself. If it was moved down a little, to show the same clear space between the text and icon, as it is on the Drive style it would be perfect.

Not as easy as simply sorting the names in the combo box. Their order also acts as a pointer to the actual preset structure array.



Ah, but if you want to prefix a preset with a theme name, you probably need long strings...

Anyway, I think this might be a bit too much nitpicking - I doubt users will create so many presets that ordering becomes an issue.

Besides (and this relates to BassDudeNZ issue) just like a theme is capable of altering the colors of the iconic analog clock to match the theme, I might do the same with the drive meter.... haven't decided yet.



The text cannot go down any further, it is as low as it will go in the icon. What you are reporting is not because of the text position but because the ring chart image, being a circle, extends a bit more further down than the drive image.

This "text overlap" also happens with other icons (for instance, the weather icon when displaying a sun or a full moon) and it was never an issue.

Anyway, the only solution in this particular case would be to make the text of the ring chart slightly smaller, but that comes at a cost of readability.

####

In the mean time, re-organized the troubleshooting dialog as I needed to fit a new "View Disk Meter Status" button to troubleshoot any issues with SMART data retrieval.


As I mentioned in a previous post, had the temperatures of two drives get "stuck" so I added some diagnostics information to the service and this dialog will help find out why:

From a graphical perspective, I think you might only need to make it a little thinner, not smaller. Not a lot. Try it anyway. If it works it works, if it doesn't then nothing changes. Either way the readability will not change.

Good idea, slightly reduce the outside diameter of the circle and leave the text as it is now. that would give a little space between text and icon.

from aligning graphics and modules a lot lately in design, just looking at it, I feel it would not need much more than 3 pixels off the outer circumference to fix the text overlap. 5 pixels at the most, and that may be too much.

Didn't say that you didn't - just that you might want to provide a cap anyway (to prevent it being too long!).

Anyway its your call..

It's beginning to look like "something"

That does look good

And it did, and it's fixed. Actually very complicated stuff among other reasons because the code runs multi-threaded (the app part where the application requests info on some drives and then the actual data gathering part that is run on a timer).

The service continued polling SMART data even as the system was entering sleep or hibernate. At that point, the lower‑level API refused to respond and blocked until the system resumed - often many minutes later. Because the timer kept running, the service misinterpreted this as the drive taking longer than 10 minutes to respond, which triggered the “do not query again” flag.

Before applying that flag, the service now checks whether the delay was actually due to the system being in a low‑power state. If so, the delay is ignored, rather than ignoring the drive from then on.