!Alarm not setting time from network

Hi all,
I seem to be having a problem with !Alarm
In the options for time and date, I have “Set from network” radio icon selected and “Pick a server automatically” checked.
“uk.pool.ntp.org” is greyed out and to the right of the “Try” button I have “Not connected”
I’m fairly sure I am as I’m typing this on the same machine!

Hardware is RPi3B with the latest ROM (beta30Mar16), HD4 and firmware I could find.
I also have the same issue with an RPiB with 27Mar16 ROM and old RPiB with 20Dec15 ROM

Is it me doing something fundamentally stupid, (wouldn’t be the first time and certainly won’t be the last!) :)
Or is there a problem?

As I type this, old RPi has corrected itself. Now showing “Sync success”

I’ve seen the same issue at my end once or twice and figured that it was just my ISP playing up (problems aren’t rare and I’m changing to a competitor once it comes to my town!)

It’s interesting that it’s not just me. It does seem to work eventually… bizarre.

Hi Chris,
I’m with BT and currently have the older setup and the new setup running at the same time, side by side. Both are plugged into the same network switch. The old one has just shown “Sync success” again, but still nothing updating on the latest.

Although to be fair, the network cable on the old is 1m long and the new is 2m long. Must be a delay in the cable! :)

Note that since RISC OS v5.19 it is not Alarm (or Organizer) that sets the date and time, because RISC OS was changed to handle it within the OS (where it should really always have been). Both Alarm and Organizer were changed so that if ‘set clock’ was selected they just invoke the RISC OS Configuration for Date and Time (which is also available directly).

I supect that the ‘not connected’ means just that – it has not (yet) found an internet connection. Perhaps the internet is only checked by the configuration plugin at intervals?

I’m with BT

I’m not; I’m on the other side of the world so chances are that it isn’t an ISP issue :)

Both Alarm and Organizer were changed so that if ‘set clock’ was selected they just invoke the RISC OS Configuration for Date and Time

Yep, I just assumed that the mention of Alarm was just a “typo” (for want of a better word). Personally I was using Date and Time directly.

Having seen thiss topic, I tried to update the time on my Pi 1 (using !Alarm) and got a response of ‘Busy’. This was repeatable both with pool.ntp.org and with my ISP’s time server.

So,I re-booted the Pi (which had been running for months) and everything is OK now.

Is it me doing something fundamentally stupid

I suspect so!
My method of updating the rom image is using the live machine.
Go into the LOADER directory, rename the old image RISCOS/IMG > RISCOSxx/IMG, then drop in the new image in.
If I’ve done a Shutdown rather than a CTRL-BRK then the outgoing OS may have updated the CMOS bits on the new image and potentially corrupted it.
I’ve just downloaded the 30-Mar-16 image again and it seems to be behaving itself now. Sorry for any trouble!

If I’ve done a Shutdown rather than a CTRL-BRK then the outgoing OS may have updated the CMOS bits on the new image and potentially corrupted it.

On the other hand, if you’ve done a Ctrl-Break rather than a proper shutdown, the CMOS will be in a default state which I suspect is more applicable to a machine of the ‘90s than now.
I have not looked at the SDCMOS code, but I’d be rather surprised if it just blindly spewed data into the image without first verifying that this was a legitimate thing to do…

I always do Ctrl-Break after updating the ROM; I do need to set the screen resolution and a couple of other things again, but I too have had the “corruption” issue if I do a shutdown. From memory, the issue was something to do with Unplug bits pointing to the wrong modules since they can get different IDs in an updated ROM (I think this was particularly an issue when going from 5.21 to 5.23).

I have not looked at the SDCMOS code, but I’d be rather surprised if it just blindly spewed data into the image without first verifying that this was a legitimate thing to do…

I’ve just looked at the code (cddl.RiscOS.Sources.HWSupport.SD.SDCMOS.s.sdcmos) and although I’m a novice when it comes to assembler, it does seem to re-check for the correct byte range when writing. I doubt that it’s corrupting the ROM itself, but rather writing data that is no longer compatible with the new ROM.

From memory, the issue was something to do with Unplug bits pointing to the wrong modules since they can get different IDs in an updated ROM (I think this was particularly an issue when going from 5.21 to 5.23).

Back in the days of infrequent real ROM updates the official change sequence included reinserting all unplugged modules so re-arranging the order of modues didn’t leave a required module unplugged.
These days in worst case that would mean unplugging the cmos chip or deleting the file. You do of course lose all saved settings.
With a setup with “cmos” settings embedded in the ROM then replacing the image gives you default settings.