ScoreCards

[Yincognito]

Any suggestions on how to fix these errors?

Those errors seem similar to mine in the past. I was just testing the skin at that time and used football / soccer for it, so it might not be your case, but I think the cause of the errors is largely the same (some data that can't be retrieved, leading to various formulas missing the corresponding element / value). I'll let jake2456 answer this in detail if he's still active or has the time for it, since it's his skin and all.

[jake2456]

Those errors seem similar to mine in the past. I was just testing the skin at that time and used football / soccer for it, so it might not be your case, but I think the cause of the errors is largely the same (some data that can't be retrieved, leading to various formulas missing the corresponding element / value). I'll let jake2456 answer this in detail if he's still active or has the time for it, since it's his skin and all.

I do believe yincognito is right. That error i believe has to deal with the date and time conversion formula. It should only happen when there wasn't a next game available at the moment it was pulling the information. I didn't get the error on ncaa football during a game but just checked the mlb and even during a game it showed the error even though all info looked to be reporting correctly so that is a little weird.

Ill try to look at the code when ive got some more free time later.

[Yincognito]

I do believe yincognito is right. That error i believe has to deal with the date and time conversion formula. It should only happen when there wasn't a next game available at the moment it was pulling the information. I didn't get the error on ncaa football during a game but just checked the mlb and even during a game it showed the error even though all info looked to be reporting correctly so that is a little weird.

Ill try to look at the code when ive got some more free time later.

Apart from potentially investigating how and why those values were missing (which from what I recall in my case back then, it was also during some games, while the errors were gone and the data provided correctly after the game ended), a quick way to avoid at least the formula errors is to (RegExp-) Substitute the empty (aka the "^$" pattern) values with some default one, like 0 for plain numbers or some default datetime for time values.

[jake2456]

From what i can see the error comes up when you first refresh or start the skin and it doesnt have all the values yet and actually has to do with the time zone measure. if it doesnt get the time zone value to complete the formula it spits out those errors. so i think the easiest way to disable the other date time measures and and do a finish action on the timezone to enable them once it gets the time zone value. might have to change the update rate on the timezone also. ill do some testing on that an see if i can get it to stop erroring.

[jake2456]

Well even with trying that(with for the most part worked) i still will get errors/hang ups when it trys pulling the values from the timezone measure. Once it is able to get that timezone value the error stops. So im not sure what to try next. Its just the webparse for the timezone seems to have trouble every now and then.

[Yincognito]

Well even with trying that(with for the most part worked) i still will get errors/hang ups when it trys pulling the values from the timezone measure. Once it is able to get that timezone value the error stops. So im not sure what to try next. Its just the webparse for the timezone seems to have trouble every now and then.

Yep, some measures - including Time ones - are "evaluated" right from the moment the skin is parsed, in order to have an "initial" value, whether they are disabled or not. Obviously, at that moment, the WebParsers won't have retrieved yet the needed values to compute the stuff in the Time measures, hence the errors at skin load. If they are only at skin load they can be ignored, but one can avoid them like I mentioned earlier: assign some initial "dummy" values (yet still making sense, from those measures' point of view) to the TimeStamp options, then, once the related WebParsers retrieved the needed data, do some !SetOption with the formulas using the retrieved values. Obviously, since the errors caused by skin parsing at skin load are not critical, making this effort to avoid the said errors is optional, up to you if you want to make it.

[jsmorley]

I would be tempted to have any measures that are dependent on WebParser measure values be set to "disabled", and then have a FinishAction on the WebParser measure(s) "enable" the dependent measures. That may eliminate the starting errors.

[Yincognito]

I would be tempted to have any measures that are dependent on WebParser measure values be set to "disabled", and then have a FinishAction on the WebParser measure(s) "enable" the dependent measures. That may eliminate the starting errors.

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

[jsmorley]

He might try:

Code: Select all

FinishAction=[!EnableMeasure MeasureTime][!UpdateMeasure MeasureTime][!EnableMeasure MeasureOffsetDateTime][!UpdateMeasure MeasureOffsetDateTime]

May not make any difference, but it might...

[jsmorley]

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.