![]() Since the plugin code doesn't know anything about the name "OHMBars", this leads me to believe it's from another thread somewhere in Rainmeter. This message appears in log in the middle of a constructor call in my code during a call to initialize the connection to the OHM WMI server. WARNING: (00:00:00.281) MeterWindow "OHMBars" is already active. Double click the OHMBars.rmskin that you supplied.įailure mode #1: I can get a log output that has the message you saw: I can trigger two failure modes by doing this: JS: I added a ton of debug print outs to try and figure out what's happening. Here is a test skin if you want to play with it: ![]() Lua skins and it really seem to hate each other in particular. rmskins even with only one running and trying to load anything else. However, it caused issue with installing. I had a skin using it running, and then tried to install another, different, skin using it. It might be possible that PART of the the issue I am was running into is related to having two skins using the plugin. The OHM skin seems to be able to coexist with other skins fine, unless a !RainmeterActivateConfig command is sent via the command line. WARNING: (00:00:01.812) MeterWindow "OHMBars" is already active rmskin file, I either get a crash of Rainmeter (if the new skin has a Lua script) or a behavior where the new skin is loaded but does not display unless I refresh the skin. If any skin using it is running, then Rainmeter becomes a bit weird and unstable. Everything displays as it should and it's very nice. The skins made with the plugin seem to work fine in and of themselves. Looks like there are some issues that need looking into. I can also put valid ranges on the sensor values (Load should never be above 100, Temperatures should never be above 500, etc) and if those are violated (which would indicate the wrong sensor is being read), also trigger a mode 1) refresh. I think the best solution which will fix the problem and still be efficient is to have the plugin see if it gets a different number of sensor values than it expects in 2) and if that occurs, trigger a "reset" and go back to mode 1) to refresh the sensor list. Clearly this is where your problem appears as they aren't fixed. But - this assumes that once you start OHM up, the set of sensors and the order it reports them is fixed. I was worried that if you do this every time the measure is updated, it will take forever so it switches to mode 2) when it can and just reads the sensor values. When in mode 1), it requires a lot of calls to OHM and searches for pairing up the hardware and sensors. The plugin works by doing this:ġa) read all the hardware and sensor configurations from OHMġb) repeat 1a) until the same number of sensors has been read 3 times in a row (this handles OHM's finite startup and hardware/sensor discovery time). So, the conclusion is that if you change what should be read by OHM, you have to restart rainmeter. Restart rainmeter and it gets the right values. Now I choose to read the HDD sensors (just for testing) I get: CPU core #5 temp, CPU core #2 temp and Sys temp. If I now restart rainmeter (and by that reloading the plugin) everything goes back to normal. If I after disableing HDD Sensors restar OHM, the measures give me: AVCC voltage, (what seems to be) CPU max temp, CPU total load as a number. All those give me the value shown in OHM with Read HDD sensors.īut, like I said, disable that and it gives me the CPU-clockspeed, CPU-Fanspeed and CPU VCore voltage.Įverything show up correctly in OHM, but the plugin gives me the wrong values.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |