Pmv 3.17 Blocks On Foc If Last Drive Used Is Unavailable, And sometimes even when it is! Options

[asavage]

I've noticed this in other versions, but it was really apparent today when I installed v3.71

The last time I used PMV, I was using a networked drive for opening files.

When I installed v3.71 today, the network drive was unavailable. Upon <Ctrl+O>, PMV nearly locks the system. I have three installations, and I thought it was PMV locking up, but it would seem to work right up until I opened the FOC.

The first box opened the FOC, and populated it with placeholder icon, but locked up when drawing the thumbnails. The other two wouldn't even draw the FOC; they just became zombied when <Ctrl+O> and the last drive was a non-available network drive. They would not immediately kill via the Tasklist, but given enough time, they did eventually die.

When I rebooted the server (the network resource for image files), and restarted each PMV, they seem to work OK.

I have noticed bad behaviour in the past WRT the FOC and networked drives, sometimes to the point of having to reboot the client box, and at one time this was bad enough that I just didn't use PMV on networked drives, but the last two years this has been less of a problem, though it would still become unresponsive when <Ctrl-O> on a network drive and I'd have to kill & restart it. In those cases, it would always lock up during populating the icons in the right pane; either it wouldn't draw all the placeholders, or it wouldn't finish creating the thumbnails.

I've put off posting about this bug for years, because it seemed like too much work to track down for what I perceived to be an OS/2 networking-related issue, but I have had it happen at least once on a WinXP SP3 box, just last week. I've no idea about how to approach fixing it, but I thought it would be a good idea to document that at least one user is having a problem WRT the FOC and networked drives.

I do 90% of my work with images on an OS/2 server. Lately, I've been doing a lot more than previously, so the frequency of problems is higher.

[later]
FOC locks up with 3/4 of the FOC saying "can't create thumbnail" and two icons saying "creating thumbnail". CPU at 100%, mouse moves but is showing an OS/2 clock cursor. I was able to grab a camera and take a picture, as it turns out the box had to be rebooted -- the screen remained unchanged for 30 minutes.

[later]
I just updated my WinXP box to v3.71, and saw some odd FOC behaviour too, noted in the second picture below: the left pane does not fully populate all of the mapped drives until about 45 seconds have elapsed.

Here's a couple of pics. If the links don't work, my broadband is down again.
Screenshot via camera: OS/2: box locked up at FOC

Screenshot via camera: WinXP: PMV locked for 45 seconds.

I'm off to backlevel to v3.70 (on the OS/2 boxes at least).

Sidebar for the Win version:
While I'm thinking of it: Win version: when I have a whole lot of files on a network drive and the FOC has generated thumbnails, and I dump a new file in that remote directory via another app, then bring up the FOC and refresh (F5), on the Win box there is no indication that the refresh is occurring.

For example, using PhotoShop, I just put those two pics above in a directory I was working on with PMV. I wanted to bring the PSD file in PMV. I opened the FOC and saw all the existing thumbnails. I pressed <F5>. The new PSD file has a filename which sorts it to the end. It took around ten seconds before the new placeholder icon (and eventually the thumbnail) appeared. During that 10 seconds, there is not user feedback that the refresh is occurring. I, as a long-time user of PMV, am used to this, but every so often I forget to "wait for it", and during this interval I'm thinking that something has gone wrong.

As an enhancement, some kind of visual indication that a refresh is in progress would be a good idea.

[asavage]

I worked with it several hours yesterday, and with on-the-fly and *.* it did not have the 100% CPU problem (although I got several out-of-memory dialogues, and when it does that it closes).

=============================================
I normally run two PMV windows. I scan two pages at a time on my large-format scanner. I open the scan in one PMV, then copy half of the scan to the clipboard, then in the other PMV I Edit->Paste->As New (<Alt+E,P,N).

Often, the copy to clipboard fails and PMV closes, so I have to open PMV again and load the scan again, this time cropping to 1/2 size and saving a single page to open in the other PMV.

[later edit: actually, if I <Ctrl+X> a small section of the large scan, prepatory to a Paste, that's when I would see this behavior. I think I also saw it on a copy to clipboard, but I'm not so certain about that any more.

In the Win version, on XP SP3, copy to clipboard often silently fails with large copy operations. PMV doesn't say the copy to clipboard fails, but there's nothing to paste elsewhere.]

I have Undo enabled, which doubles the mem requirement. I can't do without Undo.

It would be nice if PMV did not die when it gives the "out of memory" message.
=============================================

FWIW, with 200Mb scan files and on-the-fly for thumbnails, it's a very slow process to work continuously with PMV. The outline of the thumbnails is not shown, nor the file names, until it has read the file (that's apparently what's going on; the actual mechanism isn't apparent), so if I open a dir with, say 1.6Gb of scans, it's minutes until I can even click on one, since there's not even empty thumbnails in the FOC.

I never knew this before, because I never use on-the-fly.

[Peter]

I worked with it several hours yesterday, and with on-the-fly and *.* it did not have the 100% CPU problem (although I got several out-of-memory dialogues, and when it does that it closes).

That's what I'm afraid of: The reason for the hangs you are seeing are most likely because it hangs during processing of EAs (Extended Attributes) in the file system driver. This could explain why I can't repeat the problem here (different system configuration).

Now that you mention it, it's possible that the file system driver works flawlessly under normal conditions but hangs in low memory conditions. Repeating the situation may be difficult.

Actually, when thinking more about this, I guess there's a chance that the problem is in PMView too and is caused by an out-of-memory situation where memory is allocated directly (not via C++ new/delete). I will have a quick look at this and see if some improvements are needed.

It would be nice if PMV did not die when it gives the "out of memory" message.

PMView was conceived back in 1992 when 32-bit OS/2 was brand new, most machines had 16MB memory or less, and nobody could imagine hitting the 2GB (later 3GB) 32-bit barrier of the operating system. Actually most developers did not realize that this addressing barrier existed, or envisioned it would somehow be solved the day that much memory is needed. (Microsoft fixed it on Windows by moving to 64 bits).

Consequently I designed PMView to assume memory is always available. The "out of memory" message is actually a fairly new addition that was added in PMView v3.24. The message is displayed once PMView catches a C++ runtime out-of-memory exception. At this point it's already too late to do anything fancy.

Today the problem can be solved by switching to 64-bits, so it just does not make sense to spend a lot of time on reworking all existing code to handle the situation. That time is much better spent on adding new features and fixing bugs.

FWIW, with 200Mb scan files and on-the-fly for thumbnails, it's a very slow process to work continuously with PMV. The outline of the thumbnails is not shown, nor the file names, until it has read the file.

The file names (and thumbnail placeholder outlines, if applicable) should be shown almost immediately UNLESS you have configured PMView to sort files based on a criteria that requires examining the files in detail (file format, image size, image depth, etc.). As long as you sort by a feature that is available by a common "dir" statement, file names and outlines should appear almost immediately. (When EAs are used, PMView store the additional info in the EAs, which is why you can sort on any criteria and still keep it quick).

Thumbnails are added by a background thread, so they should appear one by one (slowly if you have really big files).

[Peter]

FWIW, this great article may be of some value:

http://www.os2voice.org/VNL/past_issues/VN.../feature_3.html

[asavage]

FWIW, this great article may be of some value:

http://www.os2voice.org/VNL/past_issues/VN.../feature_3.html

That's a great article. I read it entirely, and while I do not claim to understand it all, it's still enlightening. Thanks for the link.