@Daedalus

I think it's been like that "all the time", i.e. since it was created for OS4 back in the early naughties.

As for switching between the audio and data tracks, in SYS:Documentation/CDFileSystem.doc you can read:

Quote:

Perhaps that is what you need? I haven't tried it myself (not sure if I have any audio CDs with data tracks).

Best regards,

Niels

It would probably be a very good bet to test for >= 54.47. I can't imagine a reason why the fix wouldn't be in the next beta kernel, where we currently have 54.46.

But yeah, we can't know for sure until it's released. And which version will make it to public (and when) is another question altogether.

Best regards,

Niels

@sailor

I have issue 147.

The cards mentioned in that article are Radeon HD 7750 and 7850, and the monitor is an Iiyama ProLite XUB-3493WQSU.

Best regards,

Niels

@mr2

Many monitors have a setting to select autoscaling on or off, have you checked whether yours has?

Best regards,

Niels

@LiveForIt

Quote:Good idea - in principle.

But first: "They" would be Rigo, who is the author of AmiUpdate and the database and server infrastructure behind it.

And while he could of course implement an MD5 check into the AmiUpdate program and a new field in the database to hold the MD5 sum, it would also require someone (or more likely something, like a script) to calculate the correct MD5 sums of each and every application maintained in the database, which would involve downloading it from the path indicated in the database (hoping the network and servers stay up during the process, and no application is changed in the meantime). And recalculate it every time the application is updated.

I don't see that happening any time soon.

But hey, I believe there is in issue tracker on the AmiUpdate web site (amiupdate.codebench.co.uk), you could always make an enhancement request there.

Best regards,

Niels

@nubechecorre

Try setting your language to English (i.e. remove the languages in Locale Prefs and let it default to English).

Then with your older AmiUpdate search for updates using the English UI and get the new 2.49 AmiUpdate as well as the latest Italian locale for it (and/or whichever other locale you may want).

Deselect any and all other updates, so they don't interfere for now.

You may get an error and some Grim reapers when trying to exit AmiUpdate, but just ignore them and do a reboot.

Afterwards, you should be able to set you preferred language(s) again, and hopefully the texts will be where they should.

Best regards,

Niels

@Raziel

Ah, I misunderstood then. I thought it was something you ran from Network-Startup to check whether the network was up before continuing.

Best regards,

Niels

@Petrol

Yes, and the same goes for the prefs_updates (as mentioned in the other thread). The one in the separate archive is 145172 bytes, while the one in the full update is 151060.

I'm wondering why there has to be a separate product for the library and the prefs program, when everything is already in the main archive. Much too much that can go wrong this way - and as we have seen, Murphy's Law is still in effect.

Best regards,

Niels

@Raziel

Quote:I also just see the grey screen. Looking at the page in Inspector, it seems to be rendered by some massive JS scripts (which I didn't try to dechipher ). Probably beyond what we can expect Odyssey to manage.

Best regards,

Niels

@Raziel

Yes, you are of course right, there isn't any check in the script per default.

Usually, you can just get away with the Wait I mentioned earlier, but of course it's still no guarantee.

Your solution is much more failsafe, but also rather complicated.

What I do, and what normally serves me well, is I have the following lines in my Network-Startup after the AddNetInterface:

---8<---
Wait 5 SECS

GetNetStatus CHECK INTERFACES,RESOLVER,DEFAULTROUTE
If WARN
Wait 3 ; Increase chances of IPrefs having opened the final WB screen
RequestChoice "Network Startup" "Network not operational,*nS:Network-Startup aborted" "OK"
Quit
EndIf
---8<---

It's still not perfect; I remember Olaf saying something about GetNetStatus not always being able to determine for sure if things were up, but it's at least more concise and actually mostly works.

Maybe a matter of taste (and network conditions).

BTW, when you write about giving control back to the system, don't forget that Network-Startup is already being executed asynchronously, so in effect you're just exiting it, the system already has control and proceeds to boot WB while we start the network (which is why starting network-demanding programs from WBStartup is not such a great idea, as mentioned above).

Best regards,

Niels

On one of my partitions, I chose to not auto-update AmiUpdate at the start, but wait and let it list all updates.

It showed both the main, full AmiUpdate update and two separate updates for the prefs program and the library, respectively. When I let it update all three in the same go, I ended up with corrupt (truncated? at least shorter) versions of the prefs program and the library.

Trying to scan (after rebooting) created a GR with a stack trace with lots of expat.library addresses in the stack.

Then I replaced the two modules with the same ones from the main AmiUpdate archive, and all is now well.

So a general warning: If you also get those two updates presented, don't accept them. Only install the main AmiUpdate archive, then the next run will not present the others, since those versions are already installed (in complete and healthy variants).

Best regards,

Niels

P.S. Disclaimer: I could of course have gotten corrupt downloads of those two archives due to network hiccups, but I doubt it, it's not that likely to have happened to two out of three downloads right after each other.

BTW, I don't think AmiUpdate has anything to do with this, so why refer to it in the subject?

Best regards,

Niels

@rjd324

No, mine is not fixed. But I'm not convinced it's the same thing. Anyway, we'll see if your debug output gives more clues.

Best regards,

Niels

For anyone who are looking for a way to enter certain character like rjd324 did here:

Have a look at the good old KeyShow program in your Utilities drawer, it can normally give you the answer, and even insert the character into your active window (if possible, e.g. an editor) when you click it.

One of the slightly overlooked gems in AmigaOS.

Best regards,

Niels

And at any rate, I assume TimeGuard also needs the network to be up and running, so I'd recommend not starting it from WBStartup, but instead from Network-Startup. You could e.g. put a "Wait 5 SECS" (adjust if needed) after the "; Add below this line applications that need a running network" comment line, and then start TimeGuard - if it must run from WB, start it with WBRun. Also, if it needs it, CD to its program dir before WBRunning it, and back again afterwards (just in case you add other stuff later).

This is the reason there is a Network-Startup script: To start stuff that wants a network.

Best regards,

Niels

@rjd324

The intent of the appdir feature is that for most "normal" users, they can just use the program name in a shell (with no path) or in the default tool of a project, and it will launch the program from wherever it was last run, which would normally be what you want.

For some users (us beta testers for example), it can sometimes be a bit of a nuisance, and if the above description does not match what you normally want, you have to think about how (or whether) you use it. E.g. by explicitly stating paths, or by launching a program from within its directory (current dir is always earlier in the path than appdir - unless you've changed the default setup).

In cases of doubt, a "Which <program> ALL" is your friend.

Best regards,

Niels

@rjd324

Quote:But if you forgot to set the executable bit in Linux, wouldn't you potentially see the same, depending on your search path and the existance of other programs in it with the same name?

Normally, the APPDIR feature shouldn't cause any problems, because it is set to be last in the path by default.

Best regards,

Niels

@rjd324

I have the same thing on my X1000 with a Radeon HD 6670.

In my experience, if it is stuck on the black splash screen for more than 30 seconds, it won't get any further, and you might as well reset it with the button on the case. No need to wait for hours.

Sometimes it gets stuck up to three or four times before a boot finally succeeds.

I've tried inserting debug prints to serial in my Startup-Sequence, and they seem to indicate that it gets stuck in (or around) the IPrefs command.

But so far no-one in the (OS4) beta or developer team seem to have succeeded in getting any further clues to why it happens, even when running with higher debug levels.

It seems to be specific for the X1000 (not happening on my X5000/40, Sam460ex or Sam440ep).

Best regards,

Niels

@Raziel

Third.

/me hands kas1e a small Xmas present/encouragement

Best regards,

Niels

@Valiant

Salt?

Best regards,

Niels