ScoreCards

[Yincognito]

If that doesn't work, he might try setting the TimeStamp values with !SetOption bangs on a FinishAction on the WebParser measure, and have them initially set to something like 0 or whatever doesn't cause an error.

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).

[jsmorley]

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).

I think you are right...

[jake2456]

Mostly, he does. And where he didn't have, I set up stuff accordingly in an adjusted .ini, e.g. the relevant part:

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

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.

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

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]

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.

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.

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...

[jake2456]

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.

[Yincognito]

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.

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.