I know it's been a while, I've been busy with my studies amongst other things. Generally speaking also due to a lack of interest in Rainmeter, but I've just updated all of my weather skins so they only fetch location information from Nominatim if the location has changed.
Yes. This was me. I talked to the site admins and had Rainmeter unblocked. Apologies. I didn't see this until a month or so ago.
The problem has been fixed.
Droptop Four was pinging both the location and weather service every third of an hour. It now only pings the weather service (Google).
In the future, if there is an insane number of webparser pings happening at specific times, it's probably me. We've got thousands of concurrent users now, and I'm fairy sure Droptop is the most popular Rainmeter suite atm by a fairly wide margin.
I've also added a specific UserAgent that identifies all pings as Droptop pings for future diagnosis.
Cariboudjan wrote: ↑July 8th, 2024, 4:46 am
Droptop Four was pinging both the location and weather service every third of an hour.
There is something I don't understand from their complaint though: they said the calls were at precisely the same time, 3 times per hour. But here's the thing: it's not practically possible that all calls were at precisely the same time given that it would be an unheard coincidence that all users loaded their skins in unison, unless one of these checks out:
- the skins were used in a 4.000 computers network, where the supposed server somehow triggered all skins to load at the same time
- the skins used Time measures instead of UpdateDivider to retrieve data at the 00th, 20th and 40th minute every hour, instead of at every 20 minutes regardless of the actual time
You probably don't know the former, but on the latter, did you by any chance used that approach to get data from the site? Just curious...
Yincognito wrote: ↑July 8th, 2024, 8:09 am
There is something I don't understand from their complaint though: they said the calls were at precisely the same time, 3 times per hour. But here's the thing: it's not practically possible that all calls were at precisely the same time given that it would be an unheard coincidence that all users loaded their skins in unison, unless one of these checks out:
- the skins were used in a 4.000 computers network, where the supposed server somehow triggered all skins to load at the same time
- the skins used Time measures instead of UpdateDivider to retrieve data at the 00th, 20th and 40th minute every hour, instead of at every 20 minutes regardless of the actual time
You probably don't know the former, but on the latter, did you by any chance used that approach to get data from the site? Just curious...
Droptop used a trunc of current minute divided by 20 with an OnChangeAction to trigger the webparser update. Eg. at 0 minutes, 20 minutes, and 40 minutes of every hour.
Time measure is used as WebParser would otherwise attempt to update every time the skin is refreshed. Instead the OnChangeAction opens a separate ini that deactivates itself once the parsing is complete. Alternatively I could look into using a trunc of a Counter measure so that users should theoretically parse at all different times of the day.
Cariboudjan wrote: ↑August 19th, 2024, 1:33 pm
Droptop used a trunc of current minute divided by 20 with an OnChangeAction to trigger the webparser update. Eg. at 0 minutes, 20 minutes, and 40 minutes of every hour.
Time measure is used as WebParser would otherwise attempt to update every time the skin is refreshed. Instead the OnChangeAction opens a separate ini that deactivates itself once the parsing is complete. Alternatively I could look into using a trunc of a Counter measure so that users should theoretically parse at all different times of the day.
Oh, I see now - you wanted to avoid excessively polling the site on refresh by the users and instead inadvertently allowed the same because all instances of the skin requested the data at the same minutes every hour based on that Time formula. Yeah, doing a trunc of a Counter measure should indeed distribute requests about the same as non refreshed skins. Coupled with the fact that updates are only approximations of time in Rainmeter given different CPU frequencies and workloads, that should make things better in that regard.
Personally, if I were to use Nominatim, I'd let the the requests manual, whenever the user changes his location - which would be extremely rare, unless we're talking about people who travel a lot, with their laptop around. If paranoid, I'd also self unload the skin once the user searched once and chose a variant from the results, to prevent intentional clicking to search till the hand hurts. But these are just hypothetical considerations, everyone designs their skin a differently.
Yincognito wrote: ↑August 19th, 2024, 3:22 pm
Personally, if I were to use Nominatim, I'd let the the requests manual, whenever the user changes his location
Right, same here. Never could realize why a measure getting locations has to be regularly updated. Maybe I'm missing something, but doesn't really make sense in my opinion.
balala wrote: ↑August 19th, 2024, 6:21 pm
Right, same here. Never could realize why a measure getting locations has to be regularly updated. Maybe I'm missing something, but doesn't really make sense in my opinion.
Practically, it doesn't, it's not like you're in a high speed train all the time - after all, houses or cities don't move on the planet, and it takes time to get to another location. But then, I've seen weather skins updated every 18 seconds and users not understanding why they shouldn't do it (!), so it's certainly not the worst case I've seen. From the point of view of a skin designer, the pursuit for complete automation is probably one of the reasons for regularly updating everything, even when there isn't really a practical reason to do so - and I can understand that to a certain point.
Yincognito wrote: ↑August 19th, 2024, 6:40 pm
But then, I've seen weather skins updated every 18 seconds and users not understanding why they shouldn't do it (!),
