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

[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.