@Raziel

Getting back to your sound issues; the A-EON wave datatype is a streaming datatype. I would imagine that multiple instances of a notifications streaming sound from the same file could lead to problems. You might want to convert your wave sound to 8svx or aiff and see if that works better with A-EON sound.datatype. (8svx & aiff datatypes are non-streaming).

I'm having a little Radeon confusion. When I attempted to D/L Multiviewer with Updater, I checked all the files that had "updated" in the last column. One of the files that downloaded was Radeon v3.6 which is named "RadeonHD.chip.v3". When I D/L Enhancer 1.5 it has Radeon v2.22. I can't find an installer for Radeon v3.6 on my system so I need some info. Is it supposed to be in Kickstart/ as "RadeonHD.chip.v3" and added to my KickLayout or am I supposed to rename it to "Radeon.chip" and replace Radeon v2.22?

@Amigo1
I have the same problem. Multiviewer and others give me "not found on server" errors too. I wish I knew what's going wrong.

@Skateman
The things that are updated in your video are not the ones giving problems for me. It's utilities like Multiviewer, MultiEdit & Tunenet that report the error "not found on server".

@mritter0

I would include:

typedef ULONG Object; /* abstract handle */

from SDK:Include/include_h/intuition/classusr.h

Object is used extensively in GUI code.

@mritter0

I'm not sure how thorough you want to be but there is also:

SDK:newlib/include/sys/types.h

I tried to get Multiview, Tunenet & other updates with Updater and get "Not found on Server" message. Could somebody please fix the problem.

@kas1e
I'm sure Andy is doing his best to provide good software. In this case, I don't think the logviewer datatype as been used enough to bring the problems to light until now.

@all
I tried to update my Multiviewer with the Enhancer "Update" utility but I just get a message stating that it's not found on the server. Has anyone else been able to get the latest version with Update? I currently have v2.12 and Update says the latest version is v2.14.

@broadblues
Quote:

Where is the standard OS log format documentation? Some programmers might want to use the standard format for logging in a program.

We have netlogviewer, logviewer and now a log datatype. Until the logfile datatype is fixed, I would agree with kasle that logfile datatype should be removed. Having all system memory consumed and subsequent system freeze is a serious issue.

I also suggest that since the file pattern in the logfile datatype descriptor is being ignored, the descriptor hook should check for a #?.log file pattern. In addition I think that the standard log format should include a long character string at the top of the log file for better log recognition.

@broadblues
After my last post I discovered that I have the logfile datatype installed and that appears to be the problem. Also, if I load the USB log with Multiviewer then only one window of the log is displayed and there is no way to scroll down to the rest of the log file contents. However, Multiviewer displays it correctly and you can scroll down to see the entire log file. Since I can't find any documentation for a log file format that works with the logfile datatype, it seems fairly useless. Combine that with the aforementioned bugs and I think it would be wise just to remove it.

I was going to add a file pattern to the logfile datatype descriptor but there already is a file pattern in the descriptor. There is also a hook file in the descriptor which apparently overrides the file pattern.

@Raziel
I've tracked down the source of my AmigaGuide system freeze when I use a text link to a USB log in an AmigaGuide document. It appears to be a datatype file identification problem. If you enter the followiing line in a text editor and save it as a file, when you open it with Multiview/Multiviewer it is displayed with column seperators and a converted date.

I: [09:38:49] STRANGE

If you create a text link to the file containing the above line it causes a system freeze.

@Andy
Since the above issue also occurs with Multiviewer, maybe you can determine what is causing the above issue and explain it to us.

@Raziel

I was able to confirm the Multiviewer issue you reported. Hopefully, Andy's newer version fixes the issue. I also think I found an issue that occurs in Multiviewer and Multiview. In a rush to confirm your crash, I renamed my USB log ( in T: ) as text.txt to make the test. Both Multiviewer and Multiview froze my system when I linked to that usb.log file in the AmigaGuide. It's probably a text datatype issue rather than Multiviewer or Multiview. Tommorrow I will try to determine what part of the usb.log causes the problem.

@Raziel

Try @{amigaguide}
The lower case seems to work. Maybe other uppercase commands in the autodoc need to actually be lower case too.

An example amigaguide I have uses @{"Amiga" link amiga.brush/main} to display an image on a seperate page. The amiga.brush file is an IFF image file in the same directory as the example amigaguide. It doesn't work without the /main after the filename. I edited the command to link to a text file and that worked too.

@Hans
Strange that the assert() doesn't work. When I D/L billyfish's sample code, modified the test program, compiled everything and tested it the function worked. When I removed the sample.library from LIBS: and ran the test program, I got an error on the command line that was produced by the autoinit assert() for the library base being NULL. Maybe some further investigation of assert() might be helpful.

@Hans
If you are using the sample code provided in billyfish's original post, the test.c code is defective. The autoinit code will assign values to SampleBase and ISample. His test code then assigns NULL to those variables which makes it look like the autoinit isn't working.

I compiled the the library and test code with the current public SDK and it worked. If libsample_auto is in SDK:newlib/lib/ and sample.library is in LIBS: then the autoinit works when a valid test program is compiled with something like: gcc test.c -lsample_auto -o test

@kas1e
I don't think it relates to your problem but I think your code should check the return value for SystemTags() and close the 'in' and 'out' filehandles if SystemTags() fails.

Disregard my original post.
Whoever wrote the news topic "Personal Paint: Update to version 7.3c for registered customers" at amiga-news.de apparently misrepresented Amigakit's original post at amiga.org. I should have read Amigakit's post more closely. The amiga-news.de topic indicates that the update is already released while Amigakit's post at amiga.org states that it will be arriving soon.

@Raziel
Quote:
Are you sure. This would seem to indicate otherwise:

http://gcc.gnu.org/wiki/LinkTimeOptimization

After seeing a notice at 'Amiga News De' & 'Amiga.org' that Personal Paint v7.3c is available, I logged in to AmiStore but it only shows v7.3b available. When will the update actually be available at AmiStore?

@Lio
Create a script file with the following lines and add it to WBStartup.

; ClipViewer preload script
WaitForPort CLIPVIEWER
Clip PUT UNIT 1 TEXT myemailaddress

Substitute your actual email address for 'myemailaddress' and use a UNIT other than 0 (zero) so your email address doesn't get pushed out of site in the lister by normal copy/cut operations.