search

austinulmer / open-hardware-monitor

Automatically exported from code.google.com/p/open-hardware-monitor
0 stars 0 forks source link

Sometimes not all values are shown on auto-startup #253

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hello, a great tool!

I have three suggestions.

1.
When auto-startup on WinXP startup, sometimes not all values are shown.

I must do a "reset", then all values are o.K.

I think, a little delay on startup can fix it.
For example, is there an option in seconds possible to auto-startup the monitor?

2.
Can you add an option like "show the variable actual max temp of all of the 
cores in the tray in ONE symbol"? So we need only one place in the tray for 
four cores monitoring.

3.
And is it possible to run the tool without admin-rights?

My system:

ASUS P8H67-V rev.3
WinXP SP3
AHCI

Thanks a lot, Thomas

Original issue reported on code.google.com by microsof...@freenet.de on 19 Jul 2011 at 6:31

GoogleCodeExporter commented 9 years ago 
And here are the reports with error "1_*" and after reset "2_*".

Original comment by microsof...@freenet.de on 19 Jul 2011 at 3:33

Attachments:

GoogleCodeExporter commented 9 years ago 
Used suggestion (issue 269, comment 2) and give a delay of 15 seconds after 
logon. OHM now works correctly every time logged on.

On WinXP used task scheduler and a little script for delay, because WinXP task 
scheduler allows only minute-steps.

Because I have a SSD (Crucial M4, AHCI-mode), I think OHM is to quick and the 
board / sensors are not ready so fast.

Btw: the SSD reports nothing (only listed). Its a Crucial M4-64GB.

Original comment by microsof...@freenet.de on 19 Feb 2012 at 9:44

GoogleCodeExporter commented 9 years ago 
Well, issue 269 seems to be solved with "0.4.0.15 Alpha", but at quick logon 
this issue (253) still remains.
Needs a "reset" to show all data - or a delayed start...

Original comment by microsof...@freenet.de on 17 Jul 2012 at 8:17

Attachments:

GoogleCodeExporter commented 9 years ago 
I have tried to add a fix (and hopefully not reintroducing the problems from 
159).

http://openhardwaremonitor.org/files/openhardwaremonitor-v0.4.0.17-alpha.zip

Btw. do you use any other hardware monitoring apps the use WinRing0 (like Real 
Temp or similar)?

Please let me know how the new version runs.

Original comment by moel.mich on 17 Jul 2012 at 11:22

GoogleCodeExporter commented 9 years ago 
Thanks for the new version.
Because the error rather rare appearance (in the test of the x.15_Alpha the 
first error occurred today), I need some more time for testing; about a week, I 
think.

And no, no other monitoring.

I'll give You feedback here in a week - or earlier, if there is an error.

Original comment by microsof...@freenet.de on 17 Jul 2012 at 11:41

GoogleCodeExporter commented 9 years ago 
A question: is it possible that the copy of settings takes the problem? I copy 
always the "OpenHardwareMonitor.config", and it has already grown...

Original comment by microsof...@freenet.de on 17 Jul 2012 at 11:55

GoogleCodeExporter commented 9 years ago 
Please take a look at the attached "config", the values

<add key="/intelcpu/0/power/2/values" value="..........
<add key="/lpc/nct6776f/fan/4/values" value="..........
...

don't look so good. And every exit the config-file add about 1k of data.

Original comment by microsof...@freenet.de on 17 Jul 2012 at 12:16

Attachments:

GoogleCodeExporter commented 9 years ago 
No this is perfectly fine and by design. The <add key=".../.../values"....."> 
entries store the history of the sensor values for the past 24h. If you exit 
the Open Hardware Monitor and start it once more, you can still see the values 
from the past (up to 24h) in the plot. 

The values are stored in an efficient format where only changes in the values 
are recorded. The final binary stream is then gzip compressed and written in 
Base64 (http://en.wikipedia.org/wiki/Base64) encoding. That's why the values in 
the config look very strange or even "wrong", but it is exactly as it should be.

The maximum config file size should be reached if you keep the Open Hardware 
Monitor running for 24h. After that, there can be minor fluctuations in size 
(because of the compression), but it won't continue to grow.

Original comment by moel.mich on 17 Jul 2012 at 12:39

GoogleCodeExporter commented 9 years ago 
Thanks for the explanation.

The error today occurred again, also at V x.17 Alpha.
The error does not occur when I make a startup-delay about 15 seconds long via 
a script (tested over some month). "Run on Windows Startup" in OHM is then not 
set, of course. The script self starts via the Windows Task-Sheduler, "run on 
logon".

Original comment by microsof...@freenet.de on 18 Jul 2012 at 7:21

GoogleCodeExporter commented 9 years ago 
That's bad news :P

Can you save a report once more the next time it happens (before you fix it 
with a reset) so I can see what went wrong.

Original comment by moel.mich on 18 Jul 2012 at 7:35

GoogleCodeExporter commented 9 years ago 
OK, here is all I have! :o))

Original comment by microsof...@freenet.de on 18 Jul 2012 at 7:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Thank you. Unfortunately I can not see where the problem is from the report. So 
I have created a new version with more debug output in the report. Hopefully I 
can see from a new report with this version where the problem is.

http://openhardwaremonitor.org/files/openhardwaremonitor-v0.4.0.19-alpha.zip

Original comment by moel.mich on 18 Jul 2012 at 8:22

GoogleCodeExporter commented 9 years ago 
So far, no error has occurred. Test goes on...

Original comment by microsof...@freenet.de on 24 Jul 2012 at 7:28

GoogleCodeExporter commented 9 years ago 
Nothing happens, no error has occurred. Test goes on...

Or is vxxx.19 alpha the solution, because the "debug-code" make it a bit 
"slower"? ;-))

Original comment by microsof...@freenet.de on 1 Aug 2012 at 8:18

GoogleCodeExporter commented 9 years ago 
Well this is not so bad, its always good to have no error to fix. Btw. you can 
also keep using the latest 0.5.1 Beta version, the debug code is in there as 
well.

Original comment by moel.mich on 2 Aug 2012 at 7:45

GoogleCodeExporter commented 9 years ago 
Here it is: new error on my laptop, see attached reports (first Error and then 
AFTER reset).

Original comment by microsof...@freenet.de on 11 Aug 2012 at 4:56

Attachments:

GoogleCodeExporter commented 9 years ago 
Thank you very much. I am still pretty in the dark why it actually fails. So I 
have added more checks and a few delays in critical situations to give the OS a 
better chance to act the way it should.

http://openhardwaremonitor.org/files/openhardwaremonitor-v0.5.1.2-alpha.zip

Original comment by moel.mich on 11 Aug 2012 at 9:52