New Zealand Local Weather Forum
Weather Discussion => Hardware Software and Technology => Weather Display => Topic started by: choc-a-holic on March 20, 2016, 01:27:11 PM
-
I have recently rebuilt my PC, re-installed WD to old version I was running and then upgraded to latest version. Prior to the rebuild, I used to get the data logger window at startup that showed the down loading of missed data whilst WD has been offline. It had the manual adjust start time on the right of the window. I no longer get this.
I have used the manual adjust start time a number of times in the past when I have station and/or PC issues.
I see the data logger option in the control panel which will allow you to adjust the timing there. Is there a way to get the old data logger window back as I liked how I could just quickly change this at startup? I have had a good look around trying to find an option to turn it on without success.
-
HI
what weather station type?
-
WMR200. You fixed my other problem just recently with the control panel not showing the right temp and you issued a fix for me. I have since gone to ver 10.37R320. They are having problems with my clientraw not being read by the the weather map on this site so I went to the latest to see if it fixed the problem.
-
the latest .zip update has the ability to set the date/time to get the data from in the new wmr200history.txt file
not sure about your clientraw.txt file problem
(not enough information to know)
-
Can I clarify versions with you....if I am running ver 10.37R320 (downloaded on the 20th March) and the download folder has the same version dated 23rd March on it - does that mean it's a newer version? I would have thought the release number would increase.
Jenny is working on the clientraw.txt live map issue. For some reason the live map on this website no longer picks that my clientraw file is being updated and thinks my station is offline. This all happened since I upgraded. Jenny noticed the problem and contacted me about it - she is looking into it at the moment. It may be another upgrade issue...just waiting to hear back from her.
-
the release number has not increased
but that does not mean its not a new version update
(as you have discovered it is by checking the file modified date)
-
Brian for some reason neither the Map Script or the Data Summary script can read Mahana's clientraw.txt.
Today I cross checked her clientraw.txt against yours as you have the same version 320. Both were identical in data count so I am baffled now. Our scripts are reading yours fine Brian.
Next step = annoy my guru :)
Cheers
-
the script is returning a 200 OK response every 5 mins for Mahana. I presume that means the script is finding the file ok, but may or may not be reading it ok.
Just a thought, are there any hidden characters in the clientraw.txt file eg a CRLF in the wrong place? Not sure why that would occur but at this stage it's the only thing I can think of
-
are you able to add to the script to create a copy of the file when it blows up?
-
choc-a-holic; after you had your crash, when you first came back online our scripts read in your clientraw.txt fine. No problems at this point.
Following you went offline for a day or so and then back online.
From there our scripts could not read your clientraw.txt
So...... if anything, what was different when you returned online the second time. Had you changed anything. Had you upgraded WD at that stage.
Cheers Jenny
Brian; Mahana's clientraw.txt is exactly the same as yours so I am mystified. I am asking our guru re your question.
-
Ok I just had a brain wave :)
I took a copy of mahana's clientraw.txt and placed it on one of my servers.
The data Summary script read it in fine.
So that means your server is blocking us choc-a-holic :)
-
Something weird going on, but I don't know what !
The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!
The scripts look for and remove the leading 0d0a but from this server for some reason the check method isn't recognizing the 0d0a ?
If I rewrite the check method a different way it works ???
-
Sorry I have been away from computer over Easter.
When I returned online the second time I had upgraded to the special patch Brian gave me. I have since upgraded to 320 26th March - the very latest as of 5 minutes ago.
Nothing has changed on the hosting site that I am aware of
-
I see the wmr200history app - so do I just run this after starting WD?
-
WD runs that auto...you do not run it...as long as the switch is on under control panel,data logger
-
Further to the map - clientraw issue...an update from me:
I spoke to the website hosting provider and not getting very far as one can expect. They said is it a coding issue and check your script. I told them that the script processes around 100 clientraw.txt files from other servers without issue. They were not interested in looking further.
I did asked if they were blocking the IP address of your server as this is the only other thing I can think of. I can block IP addresses via the control panel and I checked and found no blocks.
Interesting enough - I use two android apps - weather personal widget & WDliveapp which read the clientraw.txt file without issue.
By any chance could it be an IP block on this websites server?
-
By any chance could it be an IP block on this websites server?
The Map script and Data Summary script are held on 2 different servers. Hence I doubt that is the problem.
Very strange for sure.
We know your clientraw.txt is correct. We know the scripts find your clientraw.txt but from there both scripts stop unable to read. The data summary returns this:
Ignored
Mahana 30-11-1999 00:00
Anyone else have any ideas please.
-
I just had a look at the upload options in WD...I can set up a second location to ftp the clientraw.txt file to. We could then try and read it from that location. This would help work out where the problem is.
-
I have sent details to you to upload that second instance to one of my servers.
Cheers
Jenny
-
By any chance could it be an IP block on this websites server?
The data summary returns this:
Ignored
Mahana 30-11-1999 00:00
Anyone else have any ideas please.
[/quote]
That very definitely looks like the sort of thing a data error would cause. I'd be interested in seeing the datafile (on the server preferably, so I need the URL) and the FTP log. Can you PM me those?
Cheers
-
Have pm'ed details to you :)
-
Have done some hunting around but so far no luck. I dropped the clientraw file into an editor and all seems fine there, although I didn't check it down to data field level.
I dug out some reporting, which I've attached. As an example of a successful file read I've included mine. What it suggests is that it locates the file correctly but for some reason doesn't want to read it. Anyone with any other thoughts?
So at this stage I'd like to look at the file being uploaded to an account on this server. I can have a better play with the script and also check a few other things that may point to something
-
Gabba I am pointing you back to beteljuice's post:
Something weird going on, but I don't know what !
The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!
The scripts look for and remove the leading 0d0a but from this server for some reason the check method isn't recognizing the 0d0a ?
If I rewrite the check method a different way it works.
So there is the reason why. Very strange as for years on her server it has been fine. Since the PC crash and upgrade it has not. The clientraw.txt is fine Gabba. I have compared each data entry against Brian's clientraw.txt as he is running the same version.
Now while betel can fix the Data Summary script it is not going to fix the Map script.
I can have a better play with the script...
You also better be careful with your playing...lol
Tomorrow we will test the clientraw.txt on another server.
I will let you know how we get on.
Sending the second instance of her clientraw to the forum server may be our only option.
Cheers.
-
Something weird going on, but I don't know what !
The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!
The scripts look for and remove the leading 0d0a but from this server for some reason the check method isn't recognizing the 0d0a ?
If I rewrite the check method a different way it works.
So there is the reason why. Very strange as for years on her server it has been fine. Since the PC crash and upgrade it has not. The clientraw.txt is fine Gabba. I have compared each data entry against Brian's clientraw.txt as he is running the same version.
Now while betel can fix the Data Summary script it is not going to fix the Map script.
Tomorrow we will test the clientraw.txt on another server.
I will let you know how we get on.
Sending the second instance of her clientraw to the forum server may be our only option.
Cheers.
[/quote]
More random thoughts...
Does Brian's file also have the 0d0a hex character? If I read it right the 0d0a character appears at the start of the txt string? It seems strange that WD would start adding that code now, on that PC, after a rebuild, and presumably not on anyone elses who have upgraded to that version (or at least this is the only instance where the code to remove the hex code is being executed) - so it's rather odd!
I've got older versions of WD here - I wonder what would happen if we downgraded?
It's probably worthwhile us both doing the server tests. While the scripts are based on the same code (I believe) the servers will be configured differently. I know I'm clutching at straws a bit going down the server route, but the worst thing that can happen is that we both validate what each other find ;-)
Cheers
-
0a0d are control characters, line return and carriage return
but WD does not add those, I suggest the server is adding those
-
It would be / is from the server.
It is an optional prefix to the 'magic number(s)' of whatever the server has done. (eg. gzip and / or block encoding)
Looking at the binhex string following the headers everthing looks OK.
... but the scripts fail to do a simple search and remove operation for some unseen reason !
-
it could be that somehow the server is set to ascii mode or similar?
-
Yes - that was my thinking too - I haven't seen the FTP log yet , but should hopefully be able to tell when I get home tonight, by looking at the FTP log on the (this) server side
-
Another curly one - we are using the panel in WD that allows two FTP servers to be set up.
The first FTP server works fine, and I can browse to the clientraw.txt and see it
The second FTP server gets a file of 0KB, and when it's opened up it is blank. It occasionally (roughly hourly) gets a valid file, which is then overwritten by a blank file about 10 mins later as per the ftp schedule.
Has anyone seen this behaviour before?
I've had mixed results in using the files I have managed to get on the server, so no final solution yet
-
if you can , set to use passive mode and set to rename the file too on the server
-
passive mode seems to have worked. Just doing final testing, but it looks like it works uploaded to this server, but not if the file is pulled from the other server
If that's the case we can do some troubleshooting from there, but at least we have a working solution.
Next step I think is to do a compare between the two setups and the two logs. If the are largely identical then I think the original FTP server would be the problem.
Cheers and thanks
-
I put my money on a problem with the server
-
Yep agree which is what I advised choc-a a week ago.
Choc-a I know your server does not want to know about this but perhaps you could link them to this thread and then they can read down for themselves.
Your clientraw.txt has been uploaded now to 2 other servers and our scripts can read it without a hitch.
These same scripts are reading hundreds of clientraw.txt files around the world. Tell them it is not our scripts but what they adding at their end.
Give this to your server:
The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!
0a0d are control characters, line return and carriage return
but WD does not add those, I suggest the server is adding those
It would be / is from the server.
It is an optional prefix to the 'magic number(s)' of whatever the server has done. (eg. gzip and / or block encoding)
Looking at the binhex string following the headers everthing looks OK.
... but the scripts fail to do a simple search and remove operation for some unseen reason !