Closed GoogleCodeExporter closed 9 years ago
This happens whenever the Open Hardware Monitor is not terminated correctly.
For example when Windows shuts down and doesn't give the Open Hardware Monitor
enough time to exit safely.
As a workaround you can make your changes and exit the Open Hardware Monitor
manually. All the settings are then stored in the file
OpenHardwareMonitor.config in the same folder as the OpenHardwareMonitor.exe.
To eliminate these kind of problems I will have to change two things:
- Add code to save the settings every 30min (or whenever the user makes a
change?).
- Change the code that writes the settings to a file to use a two file
approach, to avoid data loss in case the process is killed while writing the
file.
Original comment by moel.mich
on 18 Aug 2013 at 8:38
Issue 486 has been merged into this issue.
Original comment by moel.mich
on 18 Aug 2013 at 8:39
Issue 403 has been merged into this issue.
Original comment by moel.mich
on 18 Aug 2013 at 8:40
Thank you for merging my earlier report lacking documentation. (Was Issue #403
mine as well?) I look forward to seeing the more robust config storage and
will use your workaround and be mindful of saving OHM's state manually before
every shutdown in the meantime. If you can confirm the change here when it's
done then I'll know when to stop. :-)
I wonder... as much as I despise what the Windows Registry has done to software
and data independence, would saving the config in the Registry avoid this
problem by letting Windows handle the fault tolerance?
Original comment by mark.a.c...@gmail.com
on 18 Aug 2013 at 9:03
It became obvious that I couldn't be trusted to remember to deal with OHM
separately before each shutdown or restart, so I MacGyvered a workaround:
@echo off
C:
cd "C:\OpenHardwareMonitor"
del /F /Q "OpenHardwareMonitor.config"
copy /Y "OpenHardwareMonitor backup.config" "OpenHardwareMonitor.config"
start OpenHardwareMonitor.exe
This CMD file goes into my Startup lineup in place of the OHM EXE itself, and
seems to work. I don't know if rewinding the other cruft saved in that file is
a bad thing, but at least this preserves my desired gadget setup without
further hassle. I hope this will do until a more permanent kosher fix can be
implemented.
Original comment by mark.a.c...@gmail.com
on 17 Oct 2013 at 3:28
As I never intend to change the settings after the initial setup, I now denied
everybody the right to write to the config file. I hope this solves the problem
for now.
Saving the settings upon changing them seems to be the best solution. I don't
know if anybody changes those settings daily, but even then it shouldn't add
any system stress.
Thank you for pointing to the root of the problem.
Original comment by pixel.k
on 22 Jan 2014 at 11:18
I use the plot all the time to see the parameters, but after each restart the
plot window shrink and the sensor window expands, while main window remember
the size and position.
It will be nice to implement a function to remember also the sizes of those
windows to not be necessary to resize on each restart.
Thank you for your great program, and Happy Holidays.
Original comment by amiha...@gmail.com
on 26 Dec 2014 at 7:54
Issue 622 has been merged into this issue.
Original comment by moel.mich
on 30 Dec 2014 at 4:27
This issue was closed by revision r470.
Original comment by moel.mich
on 30 Dec 2014 at 5:35
The following alpha version contains the fix from revision r470:
http://openhardwaremonitor.org/files/openhardwaremonitor-v0.6.0.17-alpha.zip
Original comment by moel.mich
on 30 Dec 2014 at 5:38
Thank you. I am looking forward to starting off the new year with one less bit
of MacGyvering in my boot sequence. :-)
Original comment by mark.a.c...@gmail.com
on 30 Dec 2014 at 6:27
Original issue reported on code.google.com by
mark.a.c...@gmail.com
on 17 Aug 2013 at 10:16Attachments: