Just to let you know, jsmorley, I finally found the culprit. I took the rude approach and just commented every freaking measure or meter till nothing else but the webparser parent, aggregator and two other measures were "active". The issue was with the WebParser parent, which was like this:
Code: Select all
FinishAction=[!UpdateMeasureGroup "FeedGroup"][!UpdateMeasureGroup "FeedDerivativeGroup"]
OnConnectErrorAction=[!UpdateMeasureGroup "FeedGroup"][!UpdateMeasureGroup "FeedDerivativeGroup"]
OnRegExpErrorAction=[!UpdateMeasureGroup "FeedGroup"][!UpdateMeasureGroup "FeedDerivativeGroup"]
The thing that got the CPU crazy was the combination of Url=[&MS_Rainmeter_FeedURL]
(MS_Rainmeter_FeedURL was providing the URL to interrogate, obviously). As soon as I changed approach, removed DynamicVariables=1
from the webparser parent and set the URL using a bang like [!SetOption MS_WebParser_Feeds URL "[MS_Rainmeter_FeedURL]"]
from MS_Rainmeter_FeedURL, puff, the high CPU usage issue was gone, and Rainmeter was back to a 0.39% "normal" CPU usage (Feed skin animation included).
I have no idea what was wrong above, it all seemed ok to me, The webparser parent took the url by referencing the appropriate measure using [&measure] syntax that's described in the manual, DynamicVariables=1 should
have had no effect on the webparser since its UpdateRate
was set to one hour, etc. Could this be because I didn't set an UpdateDivider
on the webparser parent (thus making it continuously update due to dynamic variables being set on it)? Even if was that, I just followed your advice
of using only UpdateRate
on a WebParser parent, as the other options were prone to "problems", as you explained over and over on this forum...