Rainmeter Forums

Posted: **June 1st, 2020, 9:33 am**

Haha CCleaner worked for me too, thats funny.

Posted: **June 2nd, 2020, 12:30 am**

This question is not to be critical, but merely being inquisitive - I'm not a techie, so please bear with me. Why do Rainmeter weather skins quit working from time to time, but XWidget weather skins do not? What is the difference that causes the stoppage in Rainmeter?

Posted: **June 2nd, 2020, 1:55 am**

JohnBurns wrote: ↑June 2nd, 2020, 12:30 am This question is not to be critical, but merely being inquisitive - I'm not a techie, so please bear with me. Why do Rainmeter weather skins quit working from time to time, but XWidget weather skins do not? What is the difference that causes the stoppage in Rainmeter?

XWidget's use two 'core' files that access a different weather site. One appears to use Accuweather as the source for data, but I could not access the actual code, so I am not sure which other source they use.

Most recent Rainmeter weather skins use a JSON coded portion of weather.com as their source. And over the past week or so, weather.com has been offering different versions of their site, which has caused the issues you are seeing.

I hope things will settle down once weather.com unifies their code, but until then you always have the option to use Rainmeter weather skins that use alternate sources for their data; Yahoo, Dark Sky, Foreca, etc.

Here is a list of updated skins and their associated data source.

Posted: **June 2nd, 2020, 2:26 am**

I actually went an entire day today without weather.com giving me any trouble. Maybe we are seeing the end of the beginning of this.

Posted: **June 2nd, 2020, 2:38 am**

jsmorley wrote: ↑June 2nd, 2020, 2:26 am I actually went an entire day today without weather.com giving me any trouble. Maybe we are seeing the end of the beginning of this.

Gosh, I hope you are right. I enjoy creating skins, but not having to fiddle with them every couple of months!

Posted: **June 2nd, 2020, 2:43 am**

eclectic-tech wrote: ↑June 2nd, 2020, 2:38 am Gosh, I hope you are right. I enjoy creating skins, but not having to fiddle with them every couple of months!

I certainly don't look forward to parsing and creating 2,000+ lines of @Include code again if I don't have to.

Posted: **June 2nd, 2020, 11:31 am**

jsmorley wrote: ↑June 2nd, 2020, 2:26 am I actually went an entire day today without weather.com giving me any trouble. Maybe we are seeing the end of the beginning of this.

It's been several days for me of not having issues, but then, I only used the "old" weather skin a couple of times during this period.

jsmorley wrote: ↑June 2nd, 2020, 2:43 am

I certainly don't look forward to parsing and creating 2,000+ lines of @Include code again if I don't have to.

You wouldn't have to. The regexes can be constructed to parse either format (V2 or V3), actually - and after that, you wouldn't need to change it anymore, other than potentially adjusting the brackets count (although that's also quite unlikely, as their JSON format and its structure is pretty stable and straight-forward, despite the name changing and different grouping).

It's all about using elements that never (or are highly unlikely to) change in your patterns (e.g. the number of opening/closing brackets, the "root" of a field name instead of the exact name for a certain format), and look for each element individually instead of grouping it with other elements in a bigger pattern, in order to handle the changing order. For example, something like this (it's just the shortest version of the patterns, not necessarily the best one):

Code: Select all

Location=(?siU)"[^"]*location[^"]*":[^\}]*([\{\[]{1}[^\}]*"[^"]*city[^"]*":\s*"[^"]+".*[\]\}]{2})
Observation=(?siU)"[^"]*observation[^"]*":[^\}]*([\{\[]{1}.*[\]\}]{1})
DateTime=(?siU)"[^"]*datetime[^"]*":[^\}]*([\{\[]{1}.*[\]\}]{1})
DailyForecast=(?siU)"(?=[^"]*daily)(?=[^"]*forecast)[^"]*":(?:(?=.*15day).*15day|)[^\}]*([\{\[]{1}.*[\]\}]{4})

would capture all the common sections in the JSON in the children of a RegExp=^(.*)$ WebParser parent measure, irrespective of version or format. Then, in the children's children, one could have something like (just one example):

Code: Select all

(?siU)"winddir[^"]*(?-i)C[^"]*":(.*)(?:,|\]|\}|$)

which would get the wind's cardinal direction from any of the following forms:

Code: Select all

"windDirCompass": "NNW", (V2 format)
"windDirectionCardinal": "NW", (V3 format)

Iteration is handled relatively easy using day or day part index(es) based quantifiers, like (basic example):

Code: Select all

(?siU)(?:.*"\w+"){3}.*("\w+")

which would get "three" from:

Code: Select all

{"zero","one","two","three","four"}

That is, of course, if one doesn't find such methods hideously overcomplicated, the certainty of weather.com eventually switching to the V3 format to be uncertain, or the fact that I mentioned this in a weather thread to be off topic...

If you do, then sorry for bringing this up.

Posted: **June 2nd, 2020, 11:46 am**

I have seen no evidence yet that there is any need to make this super-complicated. If there becomes a real, demonstrable situation where we are randomly getting two distinct, in and of themselves consistent formats from weather.com, and that is the world we have to live in, then something like that would be required. I don't see any benefit for TWC to maintain two different formats of the JSON in the long term, that would have nothing to do with desktop vs. mobile, and while I may be missing something, I don't foresee that going forward.

Time will tell of course, and there may be a single, permanent(ish) change to the format. That wouldn't surprise me in the least. I don't see the cost-benefit for them in maintaining two, and then just randomly sending one of them out based on what, astrological signs or studying sheep entrails?

In any case, it is now going on 36 hours that the format has been stable for me, and I'm keeping my fingers crossed.

Posted: **June 2nd, 2020, 12:00 pm**

jsmorley wrote: ↑June 2nd, 2020, 11:46 am I have seen no evidence yet that there is any need to make this super-complicated. If there becomes a real, demonstrable situation where we are randomly getting two distinct, in and of themselves consistent formats from weather.com, and that is the world we have to live in, then something like that would be required. I don't see any benefit for TWC to maintain two different formats of the JSON in the long term, that would have nothing to do with desktop vs. mobile, and while I may be missing something, I don't foresee that going forward.

Time will tell of course, and there may be a single, permanent(ish) change to the format. That wouldn't surprise me in the least. I don't see the cost-benefit for them in maintaining two, and then just randomly sending one of them out based on what, astrological signs or studying sheep entrails?

They do maintain not two, but three JSON formats (V1 is still usable, you know...), actually, but that is not the question. The question is which of those formats are delivered to the user, and if the delivered format is subject to version change (like it happened recently). It might have been a temporary glitch, something exclusively cookie related, or it might be part of the short or medium term future. The thing is, they don't care which format they have in the page source (as we do, because of parsing it), since their Javascript code can read either of them - so this format switch doesn't impede their functionality in any way (which means it could happen again).

Anyway, I'm also curious how long this stability will last.

Posted: **June 2nd, 2020, 12:17 pm**

We will see. It makes no sense at all to me for them to "actively" maintain more than one version of the JSON at a time. Certainly as the format presumably evolves over time, there can be "transition" periods, much like the fact that while some percentage of the world is currently getting the new Windows 10 version 2004 delivered to them, not everyone is, yet. As you say, this transition may be painless and of no consequence to them, as they are not "parsing" anything, while it is of some annoyance to us if there is not some definable, consistent rule for how the change is rolled out to their servers. However, I resist that the long-term outlook is that they are going to randomly output the latest version or one of some "deprecated" versions without some logical basis.

I don't see this as an issue of "desktop" vs. "mobile", as that makes no sense at all to me. The entire point of JSON is to separate and segregate the "front-end" from the "back-end", so you can have one data set that can seamlessly be handled by any user interface. There is literally no other purpose for JSON or XML. There is no evidence of that in any case right now, as setting the UserAgent very specifically to a desktop browser did / does not solve the problem.

Rainmeter Forums

All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load

Re: All Rainmeter Weather Skins refuse to load