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]

. . . the FOC "gives up" trying to create thumbnails. It says it's creating thumbnails, but never does.

I should mention that closing and restarting PMV corrects this, until the next time. This is 100% reproducible here.

Hmmm. Those screenshots were on the eCS box. On the W4 box, it says "Unknown file format". That's when PMV is started with /ini=fresh though.

[later]
Ah, fresh.ini = defaults, and Icon Thumbnails is reset to Manual Create. That's the difference.



I don't seem to find a reference to that phrase that explains the difference between it and "Cannot create thumbnail".

[asavage]

Do you have PMView configured to automatically create EA thumbnails?

Thumbnail Type = Mixed
Icon Thumbnail = Automatic Create

I think that's Yes.

Try to use <All Formats> instead of <All Files> and see if that makes the behavior better.

With "List files of type" set to <All Types> (I cannot see an <All Formats> option) I can still get it to a state where it says, "Creating Thumbnail" and never changes from that.

[Peter]

Thumbnail Type = Mixed
Icon Thumbnail = Automatic Create
I think that's Yes.

Correct. Then my previous post explains the behavior - the thumbnailer and updater are busy with a previously visited folder.

With "List files of type" set to <All Types> (I cannot see an <All Formats> option) I can still get it to a state where it says, "Creating Thumbnail" and never changes from that.

Sorry, I was referring to the 100% lockup in this case. The question is if the behavior is better with <All Types> or if the same kind of problems still appear.

[asavage]

With "List files of type" set to <All Types> (I cannot see an <All Formats> option) I can still get it to a state where it says, "Creating Thumbnail" and never changes from that.

Correct. Then my previous post explains the behavior - the thumbnailer and updater are busy with a previously visited folder

I've let it sit for several minutes, and the "Creating ..." does not change. I must close PMV and restart it to see any new thumbnails at that point.

However, I can start another instance of PMV and it will load icons fine, for a directory that in the first instance *still* says "Creating...".

These are not particularly slow systems, either.

[Peter]

Another thing worth trying: Set "Icon Thumbnail -> Manual Create"

[asavage]

With <All Types>, I was unable to trigger 100% CPU. I tried for about a half-hour yesterday.

[asavage]

Is there anything else I can do to help narrow-down the area to be repaired?

The FOC is not terribly useful without thumbnails; it becomes a mere file-picker

[Peter]

With <All Types>, I was unable to trigger 100% CPU. I tried for about a half-hour yesterday.

Okay. This probably means you have a non-image file that PMView can't handle. The trick would be to find this file and send it to me...

The FOC is not terribly useful without thumbnails; it becomes a mere file-picker

Don't disable the thumbnails completely. Instead use the FOC with on-the-fly thumbnails (i.e. Mixed mode) but disable hard disk writing and generation of hardcopy thumbnails in the EA. In other words, don't enable Automatic Create of EA thumbnails. Manipulation (writing) of EAs is one area where device drivers are commonly buggy and/or not well behaved when it comes to multi-threading.

Is there anything else I can do to help narrow-down the area to be repaired?

Yes, the trick would be to find the offending non-image file that causes PMView to think it can read it and causes it to use up all your memory resulting in swapping.

I'm thinking I should probably add a restriction to PMView's file detection that causes PMView to immediately reject a file as valid if the detected image size is bigger than what the installed amount of RAM can handle. Sure, this may cause PMView to say that some valid files are invalid (although they may be perfectly fine, albeit too big to read on the system), but on the other hand this will take care of the problem that non-image files fed to PMView causes it to use up all memory and effectively bring the machine to a halt. On the same note, I should probably add a check that limits error recovery to files smaller than 10MB. The need for error recovery dates back to the 90's when people transferred files over modems, often UU/XX-encoding the files or padding them with a 512-byte header on old Mac systems.

[asavage]

I'd love to be able to hand you a file that triggers this problem, but a single file does not do it.

. . . It says it's creating thumbnails, but never does.

(click on any image for larger)

"Creating thumbnail".


When it's in this mode, the CPU is not anywhere near 100%. That's what I meant when I'd said that the creating thumbnail process seems to "give up". I'm watching this occur on one of the boxes right now, and the CPU is idling, around 3%, and the FOC shows 49 of 50 thumbnails as "Creating".

If they're all in Creating mode, and the CPU is idle, I don't think it's going to complete. I've been watching it for about ten minutes.

[Peter]

I just tried to "wander around" the file tree with <All Files> *.* set, and I got PMView to crash 100% repeatably in one directory. I isolated the problem to a .ROM file that PMView thinks is a Kodak Photo CD file (which it is not - it's the firmware for a CNC control).

So I have found a bug that could be the source of the problems you're seeing too. I'll let you know once I locate the source of the problem.

[Peter]

Ok. I found the problem. It was a Microsoft Visual Studio compiler oddity that apparently appeared with the change from IBM C++ to Microsoft back in v3.10. Now I'm thinking it's not the same problem as you have stumbled on under OS/2. That probably takes a different file to repeat...

I'll see if I can repeat it on OS/2 tomorrow when I have access to an OS/2 system.

[asavage]

Bugs squashed are always good, even it it's not *my* bug

[Peter]

Very true... I still believe the core problem is the same: there's a file that lures PMView to believe it can decode it, which leads to disaster. Of course we all want this fixed!

That said, the OS/2 compiler was also switched from IBM to Gnu C++ in v3.10, so at this time it's definitely too early to draw any conclusions. With a little luck, the bug fix might fix an issue in both Windows and OS/2!

[Peter]

Ok, as it turns out, the bug I found only affects the 64-bit version of PMView. The 64-bit version can't read Kodak PhotoCD (PCD) files at all and crashes when trying to read one. The bug has been there since the first 64-bit release (v3.60). This will be fixed in the next release.

Al, this means that the problem you're having is still unsolved. Clearly it's triggered by a non-image file on your drive. Finding that would be the key to solving the issue.

[asavage]

this means that the problem you're having is still unsolved. Clearly it's triggered by a non-image file on your drive. Finding that would be the key to solving the issue.

I have put hours into trying to find a file or combination of files that will trigger this reliably, and have failed. I've had it happen at least 50 times in the past two weeks, but I cannot present a testcase. I feel that turning up the debug and log level -- what level of detail gets written to the log -- is a method that may reveal clues.

I cannot find a file for you. It's not a single file that causes this, it's some combination of factors -- the number of files in a directory, a number of subdirectories, the mix if image and non-image files.

We have at least two problems:

1) The 100% CPU utilisation, system unresponsive;

2) The thumbnail generation process stopping forever under certain circumstances, with CPU idle. "Creating Thumbnail" forever.

How can I help?

[Peter]

Al,

We also have determined that the problem only occurs when <All Files> is selected. Choosing <All Types> solves the problem. Is this correct?

[asavage]

I thought so, but this morning I was proved wrong.

(click on image for larger)


Here's that same directory in normal conditions. It's supposed to look like this:


As I type this, it's been at 100% CPU for about 20 minutes, with <All Types>.

(If you do not see an image above, it's because I am doing server maintenance today, and there will be some outages.)

[Peter]

Ok. Then the next step is to investigate the possibility that it's an EA issue. Try using the following settings:

Thumbnail Type->On-the-fly
Icon Thumbnails->Manual Create

Thanks,
Peter

[asavage]

Thumbnail Type->On-the-fly
Icon Thumbnails->Manual Create

So far, with these settings I cannot get either problem to manifest.

[Peter]

So far, with these settings I cannot get either problem to manifest.

Excellent! Keep using that setting for a while just to make sure that the problem no longer appears. Then try chaning:

Thumbnail Type->Mixed

I believe this will work fine too. Keep it like this for a few days to make sure everyting works right.