B3033 - All time records gone mad!

[mcrossley]

Steve

I upgraded to B3033 earlier today, and I have noticed that my all time records are showing that lots of them have been set today, all at the time I restarted CumulusMX. The alltimelog.txt does not contain any updates, nor the Cumulus logfile?

[steve]

I've upgraded the ini-file component, so perhaps it was unable to read your alltime.ini file for some reason. If you dig your old alltime.ini file out of a backup and attach it, I'll try it here. have the values changed or just the timestamps?

[steve]

Ah - just noticed I have the same problem, I didn't spot it myself.

[mcrossley]

Apologies, there are some entries in the log file, but only one at the 12:00 mid-day update for a new monthly temperature record (which is also wrong)...

Code: Select all

2015-11-23 11:58:35.357 Reading reception stats
2015-11-23 12:00:00.600 Hour changed:12
2015-11-23 12:00:00.601 Calculating sunrise and sunset times
2015-11-23 12:00:00.604 Sunrise: 07:47:47
2015-11-23 12:00:00.605 Sunset : 16:02:29
2015-11-23 12:00:00.607 Tomorrow sunrise: 07:49:28
2015-11-23 12:00:00.608 Tomorrow sunset : 16:01:23
2015-11-23 12:00:00.631 Writing log entry for 23/11/2015 12:00:00
2015-11-23 12:00:00.634 Written log entry for 23/11/2015 12:00:00
2015-11-23 12:00:00.656 Writing today.ini, LastUpdateTime = 23/11/2015 12:00:00 raindaystart = 693 rain counter = 693
2015-11-23 12:00:00.677 INSERT IGNORE INTO fulldata (LogDateTime,Temp,Humidity,Dewpoint,Windspeed,Windgust,Windbearing,RainRate,TodayRainSoFar,Pressure,Raincounter,InsideTemp,InsideHumidity,LatestWindGust,WindChill,HeatIndex,UVindex,SolarRad,Evapotrans,AnnualEvapTran,ApparentTemp,MaxSolarRad,HrsSunShine,CurrWindBearing,RG11rain,RainSinceMidnight,WindbearingSym,CurrWindBearingSym) Values('15-11-23 12:00',3.4,84,1.0,4,9,220,0.0,0.0,1022.08,693.0,19.8,54,5,1.8,3.4,0.7,104,0.05,581.46,0.4,261,0.2,212,0.0,0.0,'SW','SSW')
2015-11-23 12:00:00.700 MySQL: 1 rows were affected.
2015-11-23 12:00:01.174 WU Response: OK: success

New monthly record, month = 11: 2015-11-23 12:03 83.200 "Highest monthly rainfall" 2015-11-23 11:27 83.000
2015-11-23 12:05:00.768 Writing log entry for 23/11/2015 12:05:00
2015-11-23 12:05:00.864 Written log entry for 23/11/2015 12:05:00
2015-11-23 12:05:00.946 Writing today.ini, LastUpdateTime = 23/11/2015 12:05:00 raindaystart = 693 rain counter = 693.2
2015-11-23 12:05:01.022 INSERT IGNORE INTO fulldata (LogDateTime,Temp,Humidity,Dewpoint,Windspeed,Windgust,Windbearing,RainRate,TodayRainSoFar,Pressure,Raincounter,InsideTemp,InsideHumidity,LatestWindGust,WindChill,HeatIndex,UVindex,SolarRad,Evapotrans,AnnualEvapTran,ApparentTemp,MaxSolarRad,HrsSunShine,CurrWindBearing,RG11rain,RainSinceMidnight,WindbearingSym,CurrWindBearingSym) Values('15-11-23 12:05',3.4,84,0.9,4,11,215,0.0,0.2,1022.05,693.2,19.8,54,8,1.7,3.4,0.7,100,0.10,581.51,0.3,261,0.2,208,0.0,0.2,'SW','SSW')
2015-11-23 12:05:01.063 MySQL: 1 rows were affected.
2015-11-23 12:05:01.518 WU Response: OK: success

[mcrossley]

It appears it is just the dates/times that have been changed.

[mcrossley]

No scratch that, it seems it has applied lots of the December values to November and used the date/time of when it went wrong. Did it do a partial day rollover at 12:00 noon rather than midnight?

I'll clean-up and revert back to 3032 for now...

[steve]

It seems to be assuming that dates are US format. I'll go back to the previous ini-file code and upload a fixed build shortly.

[thecivvie]

Noticed the same here, would that be the cause of the problem I mentioned

[Swigman]

I seem to have a similar issue. Is there a fix?
Ta Swiggy

[steve]

The fix for the bug in build 3033 was in build 3034 less than a day later, but if you ran build 3033 you will need to correct the timestamps yourself, the fix didn't do that.

[Swigman]

Thanks Steve,
what exactly do i fix and where?
Ta Swiggy

[steve]

You'll need to stop Cumulus and edit the .ini file(s) for the item(s) affected. If you're not sure which file it is, list the affected items here. Build 3033 is quite old now and was available for less than a day, so presumably this happened some time ago, but you've only just noticed?

[Swigman]

Hi Steve,
i figured the easiest way was to zip up the records output along with the .ini's so you can see the issue. Then if you tell me what to edit i can fix it.
Thanks Swiggy

[steve]

Ah, so this problem only happened recently - so it's probably nothing to do with the bug in build 3033. It looks like you started MX using the US (or default) locale, so the dates are being interpreted incorrectly, with months and days swapped. As long as the files don't get written, the error doesn't appear in the ini files. So your alltime.ini file is OK, for example, as it hasn't been re-written. but your month.ini and year.ini have the dates in US format. Your monthylalltime.ini file may also be affected. Today.ini is

You will need to stop MX and either edit the ini files to convert the dates back from mm/dd/yyyy to dd/mm/yyyy, or restore good versions from a backup.

The plan is to change MX to store dates in the ini files in ISO format (as I've already done with the timestamp in today.ini) so that accidentally changing locales is less of an issue.

[Swigman]

Thanks Steve,
Where do you set the region to make sure the date stays the same? Is this an OS thing or MX thing? I was initially running MX on my windows system and it was all good. Then i installed it on my RaspPi and copied that data files across so i had my historical data on the new machine. I am happy to edit the ini's and fix it but i am worried that the underlying cfg isn't correct as i just noticed all the reported records that had the incorrect 8th of Jan time stamp are now showing 14th of Jan so something is still not quite configured right.
I do have backups of all the ini's still on my win box.

Also just a feature request for what i can only assume is probably a huge list already but it would be nice for those of us running header less mx installations to have a 'save & restart' or even just a 'restart' button from within the web page? I don't know how hard or easy that would be but it would be really helpful.

Thanks again for the awesome support.
Swiggy