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]

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.

[asavage]

I have caught up on my work for this batch. Another couple of hours of work should occur next week.

[asavage]

I had a batch of 128 jpeg files to convert in-place to png yesterday.
The directory contained those files, plus seven .php and two .html files.

Open file name = *_b.*
Type = <Custom>

Thumbnail Type = Mixed
Icon Thumbnails = Manual

During the convert process, the box went to 100%, the swap file remained at 20Mb, and the system ground to a halt. I left it run overnight, but no change by morning. After reboot, I found that it had actually converted 23 of the 128 files.

[Peter]

Hmm. Now you threw in TWO new factors at the same time, and we don't have a clue which one that caused the problem to appear.

It could be the switch to Mixed, or it could be the usage of the * mask.

Please switch back to On-The-Fly and see if that remains stable.

I'm trying to establish a setting where a problem does NOT occur. Possible problems are:
-Strange file that causes PMView's format auto detection to use up all memory
-Problems with EAs in one or more of the file system drivers on your system

However, a problem with the format detection should normally be repeatable, so it's more likely that this is a problem with EAs.