I decided to test Multiviewer thoroughly before replacing MultiView with it and discovered some serious problems that were difficult to diagnose. The crashes I found don't occur with MulitView or the Dopus4 datatypes image viewer. Here is what I found:
If the mpega.datatype is installed and activated, viewing a GIF file with Multiviewer crashes to a Grim Reaper. The stack trace shows the crash ending in datatypes.library but there is no listing of Multiviewer.
If the jpeg2000.datatype is installed and activated, viewing a JPEG2000 file either crashes to a Grim Reaper or freezes my system. If I get a Grim Reaper it only shows datatypes.library in the stack trace and nothing about MultiViewer itself.
As I mentioned above, I have no problems viewing image files with Multiview or the Dopus5 datatypes based image viewer with all my datatypes installed.
Has anyone else experienced similar problems with MultiViewer?
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@zzd10h Yes. So far setting the NOCACHE Tooltype seems to eliminate the problem. I just wonder what benefit I'm losing by setting NOCACHE (speed, accuracy etc.). Is the problem in Multiviewer or the datatypes?
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
BY setting NOCACHE you lose a little bit of speed if you need to view the same object more than once in a session, but more importantly when cacheing the data is loaded from memeory so the file is not locked by the datatypes system meaning you can use the edit file feature with auto updates when you save the edit file.
The issue with mpega.datatype is that is attempts to reopen the file to determne if it is a mp3 or not, this happens during the file identification phase (in the hook function in the MPEGA descriptor) sine there is no file with DTST_MEMORY MPEG cannot work but worse cause other datatypes to crash.
Basically it's choce between MPEGA or editable / unlocked files .
IMHO you should not set NOCACHE rather you should remove MPEGA but your milleage may vary...
@broadblues Any idea why jpeg2000 class crashes Multiviewer? Would it be possible to add options to the NOCACHE Tooltype so that specific classes don't get cached. Something like:
NOCACHE=ALL - to prevent all caching NOCACHE=gif | jpeg2000 | mpega - to prevent specific class caching.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I think he already implied that's due to the MPEGA datatype: Quote:
The issue with mpega.datatype is ... this happens during the file identification phase ... sin(c)e there is no file with DTST_MEMORY (,) MPEG cannot work but worse cause other datatypes to crash.
Emphasis is mine.
When you try to (re)open a file with MultiViewer, it asks the OS to determine the correct datatype to open the file, probably all datatypes examine the file to see if they can handle it, and with MPEGA this causes memory trashing that then causes instability (especially in other datatypes). At a guess.
So the crash is caused by MultiViewer doing more things with datatypes than Multiview did, and this has revealed a bug in an existing datatype. Personally I would have made MultiViewer look for the MPEGA datatype, and if it's version was not beyond the current (buggy) version, then automatically enable the NOCACHE option *and* warn the user about this. That way users who don't read manuals (i.e. 90+% of users) won't experience crashes & instability, and then blame MultiViewer, and (to a lesser degree) AmigaKit & AmiStore.
Any idea why jpeg2000 class crashes Multiviewer? Would it be possible to add options to the NOCACHE Tooltype so that specific classes don't get cached. Something like:
That's MPEGA again, the descriptors are held on a prioritised list and any descriptor after MPEGA is vulnerable to crash.
Quote:
NOCACHE=ALL - to prevent all caching NOCACHE=gif | jpeg2000 | mpega - to prevent specific class caching.
Wouldn't really help, because the crash is in MPEGA descriptor, and that gets tested for any dadatype that doesn't get identified first, this is not 100% gauaranteed to be in the same order every time.
And ofcourse I can't disable caching on per type basis till I've identified the datatype of the file, and it's the datatype identification process that crashes.
Any datatype that doesn't support DTST_MEMORY simply fails to load and then is loaded from disk directly as normal, so no need to switch off caching on a per datatype basis.
Detecting thr presense of datatypes class is more complex that you would think, I'm simply not jumpig through hoops like that, and getting a seperate set of "bug reports" that complain of not being able to save edited files etc.
I think he already implied that's due to the MPEGA datatype:
MPEGA datatype is only part of the problem. The jpeg2000 datatype handles 2 types of jpeg2000 files. It's a single class (jpeg2000.datatype) that handles 2 types of jpeg2000 files and there are 2 descriptors in DEVS:Datatypes. With MPEGA datatype completely removed JP2 files work in Multiviewer (with caching) but J2K files cause a system freeze when MultiViewer attempts to load them (with caching). The J2k file problems don't appear to be MPEGA related and are a problem on their own.
Who knows how many "bad" datatypes are available and it's doubtful that Andy has the time to test every single datatype that's released. It might be a good idea though to post a warning in a MultiViewer readme file warning users that certain datatypes have been identified as failing with Multiviewer in "CACHING" mode and list the ones reported to fail.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@broadblues I think people expect a little more of commercial applications than free ones.
if ( Lock("DEVS:Datatypes/MPEGA", SHARED_LOCK) || Lock("DEVS:Datatypes/J2K", SHARED_LOCK)) post a warning requester advising user CACHING problems might occur.
It doesn't seem like much of a hoop to me but you're the author. Do what you think is right for you.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
post a warning requester advising user CACHING problems might occur.
1. I would suggest only doing this once per boot, to avoid annoying the user.
2. Alternatively, use a Ringhio notification (where possible), as they don't require the user to acknowledge it (so a lot less annoying). RunInUAE does this at start-up, when the currently set screen resolution won't be full screen.
3. Alternatively, automatically disable caching (on first ever Multiviewer run), and then warn the user if they enable caching.
And if it (somehow) wrongly detects the MPEGA/etc datatypes as present (when they aren't), then option 2 is pretty harmless (and not really annoying at all).
@broadblues Quote:
Detecting thr presense of datatypes class is more complex that you would think, I'm simply not jumpig through hoops like that, and getting a seperate set of "bug reports" that complain of not being able to save edited files etc.
I hope the above provides a possible solution(s).
And anyway, if worse comes to the worst, I personally think it's still better to get bug reports about harmless misbehaviour, than it is to get bug reports about system instability & crashes...
Okay I've reviewed my notes and bug reports on the MPEGA issue.
I've had a bit of senior moment, and forgotten that we tracked down the root problem, to a specific issue in the DTST_MEMORY file handlers handling of anything that performed a DupLock, which is now fixed in the beta version of datatypes.library, the crash is in MPEGA descriptor function but the bug was elsewhere.
I'll make note in the MVer docs about compatability and versions but I'm not going to autodisable the functionality.
broadblues I think people expect a little more of commercial applications than free ones.
Yes indeed, which is why they should be hack free!
Quote:
if ( Lock("DEVS:Datatypes/MPEGA", SHARED_LOCK) || Lock("DEVS:Datatypes/J2K", SHARED_LOCK))
Whist the above may give hint that the mpega.datatype may be installed it doesn't actually prove anything, descriptors may anywhere on disk, (or in memory) the location in DEVS:Datatypes is just default / convention.
WRT to the J2K descriptor, do other files crash with it present or just J2K ones? If the latter it suggests it's a completely seperate issue, can you provide a sample file that crashes for you?
WRT to the J2K descriptor, do other files crash with it present or just J2K ones? If the latter it suggests it's a completely seperate issue, can you provide a sample file that crashes for you?
Just the J2K ones fail. It's difficult to find jpeg2000 sample images because they are not supported in some browsers and WEB sites tend to display the jpeg2000 images converted to PNG. Frequently when I D/L what is supposedly a jpeg2000 sample image it turns out to actually be a PNG.
I'm sending you an email with several JP2 and J2K images. Just for the sake of curiosity, please let me (us) know if you find the problem with the J2K images.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I'm just did a quick test on my SAM-Flex where I have the jpeg2000 DT already installed.
No lock ups here but some curious results.
Both JP2 and J2K types are correctly identified so there is no issue with the descriptors as such, however...
Both JP2 samples displayed perfectly, thumbnails formed okay and main image displayed in the tab.
Curiously in the case of the J2K samples, the thumbs formed fine but the main image didn' show at all.
That's decidedly weird as both the thumb and the image are created from the same datatype!
I'll need to do some further debugging to see if the problem is in MVer or in the jpeg2000.datatype.
I did test MVer with jpeg2000 (that's why it's on my SAM I've no normal use for it) but clearly my sample was of the JP2 type and not the J2K and so I never saw this before.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
