Yep, it doesn't. Indeed, that's why and what I suggested earlier too - seems like the only solution that would avoid these otherwise harmless errors due to "pre-parsing" various measures in the skin (I think this behavior is related to the similar / occasional errors that Lua produces - I mean, the same cause, the reading of the skin and the need for all measures to have a valid initial value, irrespective of them being disabled or not).
It is currently October 13th, 2024, 1:57 am
ScoreCards
-
- Rainmeter Sage
- Posts: 8442
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: ScoreCards
-
- Developer
- Posts: 22851
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: ScoreCards
I think you are right...Yincognito wrote: ↑September 8th, 2024, 7:59 pm Yep, it doesn't. Indeed, that's why and what I suggested earlier too - seems like the only solution that would avoid these otherwise harmless errors due to "pre-parsing" various measures in the skin (I think this behavior is related to the similar / occasional errors that Lua produces - I mean, the same cause, the reading of the skin and the need for all measures to have a valid initial value, irrespective of them being disabled or not).
-
- Posts: 93
- Joined: June 8th, 2015, 10:39 pm
Re: ScoreCards
This is exactly what i was trying. An i think you are correct, only way to essentially stop the errors is to do a dummy value. Typically id say i wouldnt worry about it since its just upon start but i saw a few times while testing where that webparse like hung up and couldnt pull the info for a few mintue and log was flooded with the error until it was able to get a value.Yincognito wrote: ↑September 8th, 2024, 7:47 pm Mostly, he does. And where he didn't have, I set up stuff accordingly in an adjusted .ini, e.g. the relevant part:Thing is, the timestamp in the last two measures still use references that don't have a value yet at the time of the initial skin parsing (MeasureTime is missing and creating that extra operation in formulas, by the way; MeasureEventDate is a child belonging to a previous WebParser that was previously enabled as well). That's why I thought some default / dummy values there, followed by setting the options to the actual values or formulas might be another way to deal with this. Unless one also has to !CommandMeasure the WebParsers in addition to updating their options' values.Code: Select all
[MeasureTimezone] Measure=WebParser URL=http://worldtimeapi.org/api/ip RegExp=(?siU).*"utc_offset":"(.*):00", FinishAction=[!SetOption MeasureTime Disabled "0"][!UpdateMeasure "MeasureTime"][!SetOption MeasureOffsetDateTime Disabled "0"][!UpdateMeasure "MeasureOffsetDateTime"] Disabled=1 DynamicVariables=1 [MeasureTimezone1] Measure=Plugin Plugin=WebParser Url=[MeasureTimezone] StringIndex=1 [MeasureTime] Measure=Time Format=%b %#d, %Y %#I:%M %p TimeStamp=[MeasureEventDate] TimeStampFormat=%Y-%m-%dT%H:%M Disabled=1 DynamicVariables=1 [MeasureOffsetDateTime] Measure=Time TimeStamp=([MeasureTime:Timestamp] + ([MeasureTimezone1] * 3600)) Format=%#m/%#d - %#I:%M %p Disabled=1 DynamicVariables=1
P.S. The way he enables the measures is his own, not mine, in case you wonder.
EDIT: Quick addition of a MeasureEventDate replacement, e.g.:Code: Select all
[MeasureEventDate] Measure=String String=2024-09-16T19:00Z
-
- Rainmeter Sage
- Posts: 8442
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: ScoreCards
A few minutes is a bit too much for a load time error, but yeah, WebParser can get hung up when abused frequently - which leads me to another point I was about to make: an UpdateRate of 1 seems a bit excessive for the WebParsers in your skins.jake2456 wrote: ↑September 9th, 2024, 12:15 am This is exactly what i was trying. An i think you are correct, only way to essentially stop the errors is to do a dummy value. Typically id say i wouldnt worry about it since its just upon start but i saw a few times while testing where that webparse like hung up and couldnt pull the info for a few mintue and log was flooded with the error until it was able to get a value.
I mean, sure, you'd generally want live sports skins to be close to a real-time updating and unless instructed otherwise via Flags the WebParser measures will cache requests and only download stuff if it has changed, but still, polling these URLs every second should be avoided. Not sure which is these sites' APIs limit of requests per day, but besides hanging WebParser, you or your suite's users could get blocked or banned for polling them too frequently. I'd go with a less intensive UpdateRate, say, 60 for a minute, or something like that. The resources you use are too comprehensive and well made to potentially be "lost" because of excessive usage. Just saying...
-
- Posts: 93
- Joined: June 8th, 2015, 10:39 pm
Re: ScoreCards
Yea i know what you mean. I havent seen an issue with the espn api but id prob be good to up it a bit. The timezone one does have limits i do believe but it doesnt really say specifics. I never intended for that one to be low as its only really needed prob once per day thing. So yea ill def have to make a few changes to regarding that. Its just one of those things you see the skin working and havent had any major errors so i just kinda forget about it.
-
- Rainmeter Sage
- Posts: 8442
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: ScoreCards
Sure thing. Something to consider when releasing skins is that the author won't be the only one using them, some users might have them loaded the entire day or similar, and in such cases one gets pretty quickly to a significant amount of requests per time unit, especially with an once per second retrieval.jake2456 wrote: ↑September 9th, 2024, 1:46 pm Yea i know what you mean. I havent seen an issue with the espn api but id prob be good to up it a bit. The timezone one does have limits i do believe but it doesnt really say specifics. I never intended for that one to be low as its only really needed prob once per day thing. So yea ill def have to make a few changes to regarding that. Its just one of those things you see the skin working and havent had any major errors so i just kinda forget about it.