the cronftp program should be picking up the settings
in the wdisplayftp.ini settings file
so just make sure the new version is using the same file
it should b as simple as that
I have had similar experiences as John, but not exactly the same. My problems had been more with the cronftpreal more than the cronftp.
Just to back up a little, previous to the new mac release I have been using Build 24 which has been running extremely well. I have had build 24 set to run the wdisplay folder under /User/name/documents with no problem.
When testing the newest releases of WD I have had problems with the cronftpreal and cronftpreal2 jobs running. Sometimes they would work for several hours and then stop, other times they would not even start unless started directly out of Terminal. Anyway, what I want to point out is that each time I tested the new releases of WD and went back to Build 24, the issues I had with the cronftpreal(s) using the new releases followed back to the older release build 24. To fix this I would replace the wdisplayftp.ini with a copy I had prior to testing the new releases and everything would then work as expected. It appears that the new WD builds does change something in the wdisplayftp.ini file affecting the cron jobs. I cannot pinpoint anything in particular as I have not had much time to continue testing but in the end, replacing the wdisplayftp.ini file with a cached one fixed my issues, somewhat similar to what Montever is seeing.
But that’s what I did, with the exception of changing the Mac comport. This is making no sense to me.
However, I will take the old settings .ini file, make the comport change, and overwrite the wdisplayftp.ini in the wdisplay subdirectory in Documents again tomorrow. It could be that somehow the wdisplayftp.ini file has problems.
Thanks, mfd38. That would explain the appearance (in my case) of a line about FTPS in the wdisplayftp.ini file for the new WD build (in Documents) that was absolutely not there in the wdisplayftp.ini file for the old build, even though all I did was take that file and put it in the new subdirectory (with the exception of the comport change).
try removing that setting
Brian,
There could be something wrong with the VP forecast tag in build 234. I have woken up this morning to find that my VP forecast is displaying about 3 different forecast eg mostly cloudy with little temp change and precipitation possible and one about rain at time with winds shifting to the nw.
If you have a look at my site www.paulwilman.com you will see what I mean.
I suspect it is adding the forecasts together when they change, not replacing them.
Paul
Ignore my last post, that really is the VP weather forecast. Never seen it so long! :oops: :oops:
Paul
It’s time for me to put this problem aside and stick with the old build for now. I recopied the old wdisplayftp.ini file from the 2014 version of WDisplay that had the wdisplay subdirectory in Application Support into the new location of wdisplay in /Documents. This time that wiped out all the ftp settings, which suddenly disappeared. Then I realized the problem with doing that was more than just the comport setting. It was that there are numerous places in the wdisplayftp.ini file in which there were entries that had explicit strings that included the old location /ApplicationSupport/wdisplay. I’d have to change all of those too.
I can see each of those causing problems because before I run weatherdisplay I remove the old version of the wdisplay subdirectory from Application Support. Those are calls to a subdirectory that doesn’t exist anymore, when I run the new version. It’s getting beyond headache producing.
I have a feeling that I am going to have to start from scratch and rebuild the ini files. Or else I can have the new version of weatherdisplay just be pointed to the wdisplay folder in Application Support, an archived version of which I have to keep on reinserting there so the old version works.
John, do you by chance use the Time Machine feature or something similar for backups, can you get a previous copy of the wdisplayftp.ini file from that which may not be corrupted?
None of my wdisplayftp.ini files are corrupted, mfd38. The one I imported to the new location is exactly what was in the old location (and, now, still is), and works with the previous version of Weather Display. I know I will figure this out eventually. But I do think you were onto something. The latest build of weatherdisplay is doing inconsistent things with the wdisplayftp.ini file when that is moved from the old subdirectory to the new one, even if the Mac comport issue is fixed (which it is in my case). The same file in the old location can FTPS…and that file in the new location cannot. Even if there is eventually a simple solution (or a less simple solution which is to start from scratch), I am going to be out of town for most of the next month. Don’t have time to do this now.
For now, the 2014 version works fine, although it begins to have crashes around the 6th or 7th day of operation. In which case, my weather station’s online presence will just go down until I return home.
you should be able to use copy/ replace for the incorrect
directories in the ini file i would have thoight easily enough
the latest version should run more stable for longer too so it would
be better to upgrade i would have thought
Brian, did you ever see this post #333 about the Noaa reports. Seems i only got the last few days of June (bummer cuz it was our hottest June ever - I wanted to see how many days were over 90).
Appears to be working now
Also let me know when you put some more debug logic in the VP import and I will test out for you (an hour or so of WD down)
Thanks
Brian
It happened again. For whatever reason my mac locked up. NO keyboard or Mouse movement would do anything. So I had to power off and reboot
Anyways… I woke at 6am and saw this happened approx 130am.
So I made a video capture of the VP import and emailed that to you.
It completed in seconds not showing the minute intervals. Anyways from the attached screen shot after it was done the graph
went from the 1 hour tick to 6am tick. I would more than greatly appreciate if you could look into this.
All my times appear to be in sync with one another (well as close as they can be)
Thanks
Brian
I sent you some screen shots of the debug info.
Also I sent you the logfile. The logfile clearly shows the data imported from 1am to 6am was SKIPPED completely
I’m hoping you agree this is a BIG issue and would appreciate looking into this.
Thanks in advance
Brian
were you able to look at the multiplier for the rainfall on the WMR 300 we have a good amount of rain heading our way tonight so will be able to test again.
Thanks
Ian
note that I am away from home currently
@DeputyDawg
via email.i am getting him to reset his datogger
You don’t have to convince me on that. I agree. It’s always good to keep up with the latest upgrade. The issue for me right now is time to do this, not whether. Right now I am also running the last 2014 Build with MacRunCheck as a backup, so WD doesn’t lock up while I am away. I want to shout out to jmar for a really fabulous program that solves so many problems…MacRunCheck
FULL reset of the VP console/logger has been performed !!!
I had yet another experience where I had to do a VP import from Davis
Once again the VP import on WD goes through the motion (kinda - you can see the times skipping minutes). But when done
there is NO data in the log files (i.e. this am stopped at 4am. I imported when I noticed at 7am - after WD Import, no data from 4am-7am in
logs or graphs
Ive been working with Brian. Reason for posting this: see if anyone else has experienced this.
new update out ,build 235,with change to wmr300 rain calculation and also a change to the davis VP extraction that should help with the problems DeputyDawg has been having