⭐ Weather.com

[Yincognito]

Actually, right now weather.com is not providing the wrong JSON data, but the right one. This is how the JSON is formatted if accessing the site with an API key...

P.S. I'm obviously talking about the format that is visible on Jeff's screenshot. Not sure about the field names though, but the structure is similar. This is something I noticed ever since the problem occured the first time.

[gerryex]

That is indicative of the "cache / cookie" problem that we have been chasing for several days now. I suspect you will find that if you take the exact steps I have outlined in:

https://forum.rainmeter.net/viewtopic.php?f=118&t=35342&p=177064#p177064

You will find that all is once again well. At least for a while. We are still chewing on this...

I know you guys are hot on the trail of this problem and I (and I'm sure others) are greatly appreciative of it.

But just wanted to let you know that I followed the steps above exactly (stop Rainmeter, clear temp files, wait 1 minute - I actually waited 4 minutes, then restart Rainmeter) and skins based on Weather.com still do not work!! Just wanted to give you another piece of information.

Gerry

[Yincognito]

Huh... here's something scary. Try running PowerShell and do this:

Code: Select all

curl -Uri "https://weather.com/en-US/weather/today/l/<your location code>" -Method Get -OutFile "c:\temp\test.txt"

What you get is the BAD data (the one that breaks the skin). And this is on a machine is currently WORKING (i.e., not having an issue). So in other words, I'm getting two different results from the same URI.

Is that "bad data" the same as when using Debug=2 option on the WebParser measure, like mentioned here, or is it different? Just curious.

[SilverAzide]

Is that "bad data" the same as when using Debug=2 option on the WebParser measure, like mentioned here, or is it different? Just curious.

NORMALLY it is exactly the same. At this current moment, I'm getting two different results. Curl is producing the "bad" format, WebParser is producing the "good" format. They should match identically in a normal world. Unfortunately (kind of), all my PCs are working properly now, so I can't test the output on a "broken" machine.

[SilverAzide]

Actually, right now weather.com is not providing the wrong JSON data, but the right one. This is how the JSON is formatted if accessing the site with an API key...

This "other" style of JSON data seems fine, but it's missing the chunk with the units of measure, which is super-annoying. Everything else is there, and might be even easier to parse since everything is in uniform arrays.

[jsmorley]

This "other" style of JSON data seems fine, but it's missing the chunk with the units of measure, which is super-annoying. Everything else is there, and might be even easier to parse since everything is in uniform arrays.

I wouldn't for one second "trust" any of the different / new formatted stuff. Not yet anyway. if this ever settles down to consistently be one way or the other, we will be able to see whats what.

[Yincognito]

Yep, figured out what is the effect that we're seeing (not what is the solution though, apart from designing a 2 format-enabled regex): weather.com is showing it's V2 (version 2) format in the browser's page source, while it delivers its V3 (version 3) format to WebParser and its download option.

One possibility is that weather.com is in the process of "upgrading" to V3. Some people (hint, hint) used to say versions are not important or they don't care about them a while ago though, so... who knows?

[Yincognito]

This "other" style of JSON data seems fine, but it's missing the chunk with the units of measure, which is super-annoying. Everything else is there, and might be even easier to parse since everything is in uniform arrays.

Yes, I know that already, as I started already working on the new regex a couple of days ago. I too find it super-annoying, the missing units. I guess we would have to explicitly set the language of the request in the first place and then set the units from an own small database on the basis of the chosen language...

At this current moment, I'm getting two different results. Curl is producing the "bad" format, WebParser is producing the "good" format.

Huh, that's strange indeed.

[jsmorley]

I just think it is too soon to try and draw conclusions. I will say though, that it is getting increasingly hinky over the course of the last few days. This is obviously going somewhere, just not sure where yet.

So far at least, if I lose my weather, I exit Rainmeter, clear the cache / cookies, wait a minute, and restart, and then it's fine. This is impossible to debug at this point.

[SilverAzide]

My guess is they are rolling this out to the machines in their server farms in stages, so which flavor of JSON you get is a bit of a crapshoot depending on which way their load balancer decides at that particular millisecond. For now. Patience seems like a good plan at this point.