MUI 4.0 keeps on expiring

Hello,

Got yet another warning today, MUI set to expire in 2 days, sadily there isn't another nightly build available yet, so when it expires I have to default back to OWB in order to get muidev.de

I seem to be stuck with nightly builds; last time I tried to hop back on the Release train the damn expiration notice still came back.

For some time now my battery clock has been broken, I use YoctoFacts to sync to an online clock everytime I boot, sometimes it fails to get the most current time - no internet connection or other reason.

All I can thing is that one of the many files in the distribution has a nonsense datestamp and I just need to 'Touch' the file to bring it forward.

Help!

@djrikki

Quote:

The other reason is if you're not running it in the right place it's probably running before the network is up. I never use it as there are system commands that do exactly the same thing.

Add:

date server pool.ntp.org port 123 >nil:
setclock save

To your s:network-startup script, this will work every time unless the network fails for some reason.

As for MUI, download the last official release and drag your MUI drawer into storage before installing the one you just downloaded. Don't forget the contributions archive.

Then using something like dopus copy sys:storage/libs/mui/ to mui:libs/mui/ and skip all existing files.

@djrikki

The latest nightly build is not older than 10 days and therefore is far away from expiring.

There is no need to complain. Nobody ever forced you to use the nightly builds. If you are not confident with the expiring mechanism then simply use the stable releases. Or check more often for updated nightly builds. These will definitely be created from scratch ahead of the final expiry date, even if there have been no changes inbetween.

@tboeckel

I tried too to install the latest nighty build to fix the expiration requester but it was still present.

I don't know if the expiration determination is based on muimaster.libary version but it was the same that my older nighty-build drawer.

But the installation of latest stable version fixed the problem.

@tboeckel, I am not complaining, I am putting out something is wrong with the way things are setup for me this end, and I do not know how to resolve.

All I know is that today it warns me, "1 day left to expire" and that the nightly build on muidev. de is dated 09/03/16 therefore surely it shouldn't be running out so soon. Don't they normally expire after 30 days?

Hi.

Not sure if we are speaking of the same problem here, but if i reinstall OS4.1FE, i get this:



Mui not registered. Now i registered MUI in 1999, and it works on one of my OS4.1FE partitions, installed a year ago, but i did a clean install presently, tried several times, but i get this all the time.

I tried putting mui.key in both L, S, and in the MUI archive, but it doesn't matter...

Anyone got a clue?

@Shamron

Not sure what your problem is, the MUI window you posted says it *IS* registered.

You might want to edit that post because it contains your address. And yes, it says it *is* registered.

I know, the pic was to prove i have paid for it. Mui settings NOW says not registered.

@Severin

Quote:

yFacts if run from WBStartup will sit in the background and sync every n minutes, so it's unlikely that running before the network is up is the problem. If it can't connect it will retry at a faster frequency.

The system commands don't do the same thing, as they run once and then exit. If you don't reboot they won't run again and the clock may drift.

@Shamron

Use Snoopy to see where MUI tries (and probably fails) to load the .key

@all with problems

Have you replaced the battery?

@Chris

Even when Iwas leaving my amiga on 24/7 the clock only drifted a few seconds a day which only started causing me problems after several months due to the discrepency between the hardware and software clocks.

@Shamron

First MUI queries the ENV variables "KEYPATH" and "KEYFILES" for path specs to contain the file MUI.key. If these two fail it searches for the keyfile in these locations (and in this sequence):
MUI:
KEYPATH:
KEYFILES:
S:
L:
DEVS:
LIBS:

If a VALID keyfile is found in any of these locations then you end up with a fully registered MUI. Just having a file "MUI.key" with arbitrary contents in one of these locations is not enough. The key file is decrypted and checked to be valid.

Perhaps your key file has been modified while copying across several systems over the years. The keyfile check itself has been left untouched and is definitely working correctly.

@djrikki

I just installed the latest nightly build by copying over all libraries and MUI prefs definitely states that it expires on April 9th 2016, which is exactly 30 days after the build date, as expected.

The AutoInstall script might be the culprit here, because the CopyStore command will copy libraries with a different version only. Hence muimaster.library will not be copied unless its revision was bumped. I also just noted that the AutoInstall script copied the class files (#?.mui, #?.mcc, #?.mcp) only, but not muimaster.library. The next nightly build will fix this.

However, installing the nightly builds is better done by manually copying all relevant files. This will ensure that nothing is omitted.

Does anybody still have this expiring problem, or is this issue invalid/solved?