But unfortunately, I won't be able to test until tomorrow. Silly me , I think I've been blocked from the weather site! I forgot to put a UpdateRate=600 on that second parent meter in my main skin, so it was likely hitting the site every second.

But I can still access the weather site in a browser, so it seems it is only blocking Rainmeter, not everything from my IP. If I don't access it any more today, hopefully by tomorrow the block will be removed.

No, by default WebParser is set to UpdateRate=600. I doubt you are blocked, it's much more likely that WebParser is "hung" from being refreshed repeatedly while testing and simply restarting Rainmeter will sort that out.

No, by default WebParser is set to UpdateRate=600. I doubt you are blocked, it's much more likely that WebParser is "hung" from being refreshed repeatedly while testing and simply restarting Rainmeter will sort that out.

Also, you were earlier using a #Variable# for UpdateRate in one or more places. Be very, very sure that that variable is defined correctly, and spelled right where used. You don't want to end up with UpdateRate=0.

Also, you were earlier using a #Variable# for UpdateRate in one or more places. Be very, very sure that that variable is defined correctly, and spelled right where used. You don't want to end up with UpdateRate=0.

Good deal. Yeah, this one will be particularly sensitive to being refreshed repeatedly before it has time to finish. This is because of the peculiar nature of it, where a "parent" is creating a "child", which is then being used as a "parent", to create a "grandchild". Nothing wrong with this, WebParser certainly supports it, but you have to be a bit careful about manually interrupting it. The first parent is going to get its knickers in a knot if it is trying to populate the child measure, while the child measure is actively being a parent and going out to the internet.