Storage changes to LibreHardwareMonitor #1
Replies: 7 comments
-
|
Integration is preferred, but a separate library is acceptable if we can maintain most of the code to not break too much 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
|
So whoever uses the sensors should be just fine as they will still be there + likely some new sensors. Following are sample outputs (may not include all available data). One NVMe: and one SATA: |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good to me, we can do away with AbstractStorage. |
Beta Was this translation helpful? Give feedback.
-
|
@PhyxionNL Just some questions to verify: Also the sensors for SSDs should be there again, right ? (for e.g. SsdSandforce, SsdIntel) Sensors for NVMes are already implemented, as the NVMe attributes are luckily standardized. |
Beta Was this translation helpful? Give feedback.
-
Yes,
It's fine to add more sensors if they make sense to monitor. Obviously temperature is useful and Write Amplification is already there (I don't find this super useful personally, but I'm sure others disagree). I don't think we have to add sensors for Power On Hours and Program Fail Count for example. |
Beta Was this translation helpful? Give feedback.
-
Ah sorry, I think markup removed the parameter from list.
Alright. Temperature is there for all by "default", same for some select others like |
Beta Was this translation helpful? Give feedback.
-
|
@PhyxionNL |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
@PhyxionNL
Hi there,
I've been working a while on a port (C#) and improvement of CrystalDiskInfo (CDI).
That will be ready soon and does support more than current LHM implementation can.
(ETA: currently planning with a couple of weeks more, including further testing)
Right now it has been tested with, I think 6-8 different (manufacturer) HDDs + SSDs and a couple of NVMes.
So far no issues and hot plug is also supported (you can be notified via an event), no matter if disk is partitioned or not.
USB devices work fine too (NVMe, HDD, SSD) and also support all SMART attributes known to CDI.
Any updates or improvements can be taken from CDI repository and pushed to CDI repository if we have some.
That would benefit both sides.
CrystalDiskInfo is licensed under MIT so that is also not an issue.
Missing at the moment:
Would you be up for either:
DeviceIoControlIntegration (copy code) in LHM can be done, but I think to match your required code style & everything else it will take a while and frankly said: I don't think I have time for that adjustment.
If you prefer that way, I assume it could be supported by Copilot or something similar, if you or someone else would like to tackle that.
At this point the code has reached 15-20k lines and is missing probably 1-3k more, while I've already removed duplicate code from original CDI.
Let me know what you think.
IMO it will definitively benefit LHM, add a lot more available data and support more disks.
I will continue with implementation soon when I've got some free time and can provide a test branch (regarding LHM integration) when all is ready.
Initial Test binaries, without source code, can be provided earlier, if interested. This will be a console + text file output only.
Source code will, of course, then be released here on github.
@DavidTobar456
Mentioned FYI, thank you for assisting with testing so far.
Beta Was this translation helpful? Give feedback.
All reactions