Cumulus Support

HansR wrote: ↑Sun 22 Sep 2019 8:04 pmThe system (CumulusMX, Mono, Linux - I do not know where the problem is) generates filename(s?) which blocks access to old data.

It is not locales applying to filenames, we do not know what is happening.

We do know some things, though. We know that Cumulus uses locale settings to name the files. We looked at your (HansR) locale and ascertained that locale settings at the OS level on your system had not changed. The one thing that had changed was the version of Mono. Therefore it follows that Mono is changing certain locale settings, and that this behaviour started with Mono version 6.

Remember that Mono/.net is an abstraction layer between a program such as MX and the underlying OS. Therefore when a program relies on locale settings to name its files then you should also remember that it is relying on that abstraction layer to pass through those locale settings correctly and unaltered. If you also remember that the same organisation is behind both .net and Mono, then you shouldn't be surprised that the same problem can occur on both Windows and Linux.

So - to summarise - I think that Mono is at fault for not passing correct locale strings from the OS to the program.

Yes, that was my first estimation as well. But I started to doubt and now I saw the Windows problem (same naming issue) in Spain in May.
That does not point to Mono. Unless Mono shares code with .NET
And apart from that, I think the C# runtime uses its own setup of local handling. So it may be independent of Mono on that level as well. It is not just passing a string from OS to Application.

HansR wrote: ↑Sun 22 Sep 2019 9:31 pmIt is not just passing a string from OS to Application.

Correct - afaik anyway, Mono implements its own locale setting independent of the OS. An older version of Mono also "messed up" locales a couple(?) of years ago iirc - a later release fixed them.

After successfully running CumulusMX 3050 with Buster Mono for a couple of months, with the latest update to Mono (24/09/2019) on Buster with CumulusMX 3052, I am getting a mono error - see attached. I have reverted back to CumulusMX 3050 but get the same error so I suspect it is the latest Buster Mono that is the problem.

Has anyone else experienced this?

Presumably removing Mono and loading an earlier version should solve the problem. I'll give it a go anyway.

What version of mono do you have installed now?

The version is 6.4.0.198. I have completely removed and reinstalled mono-complete just to make sure there were no no funnies when mono was updated but the result is the same.

Mark

I have just changed the mono entry in /etc/apt/sources.list.d to-
'deb https://download.mono-project.com/repo/debian stable-raspbianbuster/snapshots/6.0.0.334 main' and reloaded mono-complete.
This was the previous buster version as far as I could tell, but instead it loaded 5.18.0.240. This works, however, so who am I to complain.
This would point to the fact that there might be a problem in 6.4.0.198 as far as CumulusMX is concerned.

Mono 6.4?! Version 6.0 is the latest available.
There appear to be problems with version 6.0, I am going to let it stabilise before worrying about supporting it.

I have installed Buster twice recently (Raspbian and Debian) and both installs got mono 5.18 by default. Nor are they updating to mono 6, so I'm a bit puzzled why other people seem to be getting it.

mcrossley wrote: ↑Wed 25 Sep 2019 3:21 pm Mono 6.4?! Version 6.0 is the latest available.

No - they have changed to 6.4.0.198 as the current stable release [their label!]. See https://www.mono-project.com/download/stable/ which says:

Download
Release channels: Nightly - Preview - Stable - Visual Studio
The latest Stable Mono release is: 6.4.0 Stable (6.4.0.198)

The full Release notes for v6.4.0 mention a large number of issues that have been fixed - unfortunately not our one! https://www.mono-project.com/docs/about ... ses/6.4.0/

v6.4.0 has been around as a (non-stable) release since 26 July 2019. V6.6.0 has existed as a (non-stable) release since 24 September 2019.

I have been trying to work out a reliable instruction for ensuring we get the snapshot release of v5.18. It seems that is the optimal version for avoiding problems. The foillowing seems to work:

First stop CumulusMX from running.

Then remove any current version of mono
Then add security keys etc to allow installation of mono, and add the source location into the sources.list (that is where specify version 5.18 rather than allowing the latest version) Note that this mentions RaspBIAN 9 Stretch, even though we are here installing for RaspBIAN 10 Buster.
It mentions v5.18.0.268 (because that is what is delivered), though there is a warning message that it is sending raspbianstretch and not the particular version 5.18.0.268 that was requested.

Then update to find the new packages, upgrade to upgrade RaspBIAN itself, install mono and tidy up
You can check the version of mono that is installed using

Mono 5.18.0.240 was what was downloaded when I specified 6.0.0.334 as my snapshot so, as that is working, I have changed my mono source entry to that.

In view of the earlier troubles with non compatible of mono and if the only use for mono is to run CumulusMX it would seem sensible to stick with a version that works as long as it is available.

Hi all,

I'm new to all this and have spent quite sometime trying to do my own troubleshooting.

I have a Raspberry Pi3, I tonight, downloaded the latest Raspbian Buster (Release date 2019-07-10 with desktop and recommended software) - did not unzip it, used BalenaEtcher to flash the micro sd card (32GB) - followed the install instructions on this thread (added the two text files - one for SSH and the other).

I add the micro sd card into the Pi3 - and I get nothing at all. Red light on, green light on (steady not flashing); I can see it on the Network Modem by MAC Address but not IP - and am unable to access it through Putty. I've no idea what else I'm missing

Your help and assistance will be greatly appreciated.

Please note that I made an issue for Mono at the Github repository concerning the month format MMM in relation to the filenaming.

If/When that is fixed, please be aware that all people who currently are working with the dot in the filename (I noticed some do), an action may be required to correct the datafile situation (concatenation of the files) to keep a continuous datastream.

@Enforcer651: Try here. Looks like something wrong with the SD-card. Sort of try again? New/other SD-Card?

Hello to all.
I have succesfully used the Raspberry image from www.fracassi.net, with great thanks to Fracassi Andrea. The only tiny problem ist that the forecasts is in Italian language, ie " Quasi bello, possibilli rovesci a breve".
Anyone know how to change this to English?
Max

Try this.. rename strings.ini to strings.in.sav and restart Cumulus