Rainmeter Nonresponsive

[Kolano]

I identified the culprit in my case (not sure if it's the same for yours, but I'd say it's quite likely to be): the many "missing" / "incorrect" data that was queried by the OpenHardwareMonitor / LibreHardwareMonitor plugin was writing tons of errors in the log and hence slowed down Rainmeter as a whole. After commenting out or properly modifying the "invalid" parts of the code (like the measures for the fan, core, thread and temp data which I didn't have, as well as the associated meters), the CPU usage / temp / responsiveness of the skin got back to "normal" (this won't suit your case since you have different hardware, but as an example to get the idea):

Thanks Yincognito, but yeah, errors are not the issue for me. I have a i7-14700k, with 20 cores each reporting separate temperatures/core speed/usage, 8 of which with hyper-threading.


With "Update=3000" (i,e, every 3s) I can still access the Logs panel, and no errors are occurring.


Things seem to work fine on a similar setup with an i7-6700, but like you, with only 4 cores there are a significantly reduced number of measures/meters.

It doesn't seem to be a CPU consumption issue, I'm not seeing any significant CPU usage even when the non-responsiveness occurs Rainmeter tops out at ~2.2% CPU usage usually less than 1%. Things had been working well with this previously, so it seems to perhaps be related to some recent drivers or OS update that has exacerbated the problem but unclear what.

[Yincognito]

Thanks Yincognito, but yeah, errors are not the issue for me. I have a i7-14700k, with 20 cores each reporting separate temperatures/core speed/usage, 8 of which with hyper-threading.


With "Update=3000" (i,e, every 3s) I can still access the Logs panel, and no errors are occurring.


Things seem to work fine on a similar setup with an i7-6700, but like you, with only 4 cores there are a significantly reduced number of measures/meters.

It doesn't seem to be a CPU consumption issue, I'm not seeing any significant CPU usage even when the non-responsiveness occurs Rainmeter tops out at ~2.2% CPU usage usually less than 1%. Things had been working well with this previously, so it seems to perhaps be related to some recent drivers or OS update that has exacerbated the problem but unclear what.

Thanks, your screenshots help - I was hoping that you somehow by mistake queried logical processors (threads) instead of physical cores (cores) and that fixing that would solve the issue on your end as well, but now I see it isn't the case, as the code seems to correctly refer to existing LibreHardwareMonitor fields. I guess commenting out, say, 12 of your first or last (e.g. hyperthreaded or not) LibreHardwareMonitor related measures and meters on your system (like I did on mine) would make it more clear if too many of such sections play a part in the problem you have.

As for the unresponsiveness, that is almost always related to a high CPU usage, irrespective of whether it is visible or tied up to some software or not (yes, there are high CPU usages that are not related to particular software, I've encountered that before in other cases). The cause of such usage can, of course, be various things, and unfortunately identifying it is not always easy. Regarding the plugins, what I know is that the LibreHardwareMonitor one has a 1 update / second delay in terms of current values, and that the PerfMonPDH is not yet multithreaded, but that shouldn't necessarily be related to the issue since they seem to work fine on other systems.

For now, the root cause of this in your case is a mystery. Hopefully you'll be able to eventually discover why it happens and find the solution to it. Can't help much in that regard since for me the issue was solved by eliminating the sections referring to invalid data (and reducing their number as a result).

[Kolano]

As for the unresponsiveness, that is almost always related to a high CPU usage, irrespective of whether it is visible or tied up to some software or not (yes, there are high CPU usages that are not related to particular software, I've encountered that before in other cases). The cause of such usage can, of course, be various things, and unfortunately identifying it is not always easy. Regarding the plugins, what I know is that the LibreHardwareMonitor one has a 1 update / second delay in terms of current values, and that the PerfMonPDH is not yet multithreaded, but that shouldn't necessarily be related to the issue since they seem to work fine on other systems.

Yeah, I do sometimes run Folding@Home eating up background CPU/GPU resources, but even when I'm running nothing consuming significant resources I still see the unresponsiveness. As already mentioned this seems related to some recent system change, but unclear what could be responsible. Frustrating that there isn't a clearer cause.

[Yincognito]

Yeah, I do sometimes run Folding@Home eating up background CPU/GPU resources, but even when I'm running nothing consuming significant resources I still see the unresponsiveness. As already mentioned this seems related to some recent system change, but unclear what could be responsible. Frustrating that there isn't a clearer cause.

Yeah, I know what you mean - finding that needle in the haystack that causes such a problem is often a challenge. Sometimes you're lucky and the issue resolves itself for apparently no reason after doing something else, but otherwise you have to explore all kinds of possibilities in the hunt for the culprit. Generally, with Rainmeter it's easy, you just comment out parts of the code or unload skins one by one until you find it, but it seems in this case that alone didn't do it for you.