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]

Your forum software does not let me edit the Subject, so I cannot fix it.

The Subject (Title) should be "PMV v3.71 blocks . . . ", not "3.17".

Also, the re-capitalization of the Subject words is not nice. That's not what I typed.

[Peter]

Your forum software does not let me edit the Subject, so I cannot fix it.

The Subject (Title) should be "PMV v3.71 blocks . . . ", not "3.17".

Also, the re-capitalization of the Subject words is not nice. That's not what I typed.

The forum is what it is. The re-capitalization has bugged me for years.

Did you notice the new "Thumbnail Provider" option in v3.71. You may want to set it to "PMView Only" if v3.71 appears slower than previous versions.

The implementation requires a well behaved system. If a drive blocks, then PMView will wait (as you have noticed). I will consider adding the standard windows file open dialog in the next version as a solution to the problem.

Thanks,
Peter

[asavage]

The implementation requires a well behaved system. If a drive blocks, then PMView will wait (as you have noticed). I will consider adding the standard windows file open dialog in the next version as a solution to the problem.

On the OS/2 side, the wait (in previous releases) was indefinite -- I have literally left it overnight, and still had the FOC locked-up in the morning. I've never had it happen with local drives, only with remote drives on the LAN, so I'd always assumed it was network-related, but as it requires a system reboot to recover use of the system, it's a fairly major inconvenience.

For that reason alone, I'd love to have some kind of non-blocking update of the FOC for the OS/2 side of things. Thanks!

[asavage]

On my OS/2 box, it's doing it again right now. The FOC is populating the thumbnail icons, the CPU is at 100% and has been for over an hour. The system clock is still running, though it only updates every 4-6 seconds.

The directory that the FOC is loading contains only 50 image files. The directory is on a mapped remote network drive, and is available from other boxes. I can't tell if it's available to the problem box, because the system is unresponsive.

As I mentioned, this has been a problem for several versions. I generally just try to avoid using PMV to work with images on remote drives, but this is not really possible in my work environment anymore.

Is there a debug version that I can use to capture some data that can help you determine why the FOC is running the CPU up to 100% for an hour while processing thumbnails in a directory with only 50 files?

[Peter]

It sounds like you have overlooked a setting: Have you disabled the OS/2 specific PMView sub-directory scanning option: View->Scan subfolders (right click on the background of the tree)? It is on by default, but may need to be disabled on systems that have slow drives.

That said, exceptionally long processing times as you describe is a common indication that the system is doing heavy memory swapping. Do you have 4G RAM installed? Have you enabled OS/2 High Memory? (Check the System Info dialog in PMView - it will tell you).

[asavage]

I'll try that in a moment; I had given up on PMV recovering after 90 minutes, so I rebooted, and then tried navigating to the directory again, and PMV again locked up, so I'm rebooting again.

The drives (local & networked) are not particularly slow.

Scanning sub-folders sounds like something I'd want enabled, rather than disabled.

In any event, I've lost work twice today due to this problem.

[Peter]

I'll try that in a moment; I had given up on PMV recovering after 90 minutes, so I rebooted, and then tried navigating to the directory again, and PMV again locked up, so I'm rebooting again.

The drives (local & networked) are not particularly slow.

Scanning sub-folders sounds like something I'd want enabled, rather than disabled.

In any event, I've lost work twice today due to this problem.

It may be a memory issue. Nevertheless, I can't repeat the issue and I definitely do not have the resources to investigate it. Are you on the latest release of eCS?

FWIW, I hear you loud and clear: Time to discontinue the OS/2 version! I know, I KNOW! However, many PMView users encourage me to keep it current with the Windows verision, so I try to do that although I do not have the resources to debug obscure issues under OS/2.

[Peter]

Scanning sub-folders sounds like something I'd want enabled, rather than disabled.

It comes with a big penalty! This is why the option was added in the first place. Try it, and see if it makes a difference. I added the option because of feedback similar to yours 10 years ago...

[asavage]

I toggled that option off, was able to successfully save the file in the remote directory, then toggled it back on, and PMV quit.

PMVIEW.LOG:
================================================
PMView Pro v3.71 build 24898 Feb 8 2013
OS/2 20.45 build 14.105 @ 1680x1050, 32 bits
Started Sat Apr 13 17:10:28 2013

IAccessError exception thrown.
function: Unknown
file: ibasectl/ientryfd.cpp
line: 1431.
Error ID is 4097
Error Code group is Presentation System
Exception text is:
EM_SETFIRSTCHAR:UNK 1001 E


IAccessError exception thrown.
function: Unknown
file: ibaseapp/iwindow2.cpp
line: 414.
Error ID is 4097
Error Code group is Presentation System
Exception text is:
EM_SETFIRSTCHAR:UNK 1001 E



Killed by SIGABRT
pid=0x0048 ppid=0x001c tid=0x0001 slot=0x007a pri=0x0206 mc=0x0001
D:\PMVIEW2\PMVIEW.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
PMView Pro v3.71 build 24898 Feb 8 2013
OS/2 20.45 build 14.105 @ 1680x1050, 32 bits
Started Sat Apr 13 17:22:06 2013

Terminated normally.
================================================

Note: the system date is set correctly:

[D:\UTIL]date
Current date is: Sat 4-13-2013
Enter the new date: (mm-dd-yy)

I do not know why PMV is writing "Feb 8 20113" to the log, but that's what it's doing. I renamed the log and started/stopped PMV, and verified that.

[Peter]

Feb 8 2013 is the build date of v3.71. Continue reading the log and you will find the actual logging time:

Started Sat Apr 13 17:10:28 2013

The error is an IBM Open Class error. I will see if I can repeat it. Not many users are turning this option ON/OFF. It's a one time setting.

[Mark_Henigan]

I have had a similar problem. I'm hoping you won't discount it since it is related to a user whose opinion you seem to value. I have extremely large directories under OS/2 and find that I must await PMView's reading of subdirectories before I can again use PMView. But, I need at least a little depth. Is it possible to set it to read a specifici number of directory levels? Too much work? I realize that it may be due to using an underpowered T30 that I'll be upgrading to a W400, or something similar.

Also, I am shocked to hear you talking about stopping development of the OS/2-eCS version. I continue to use it for several hours daily despite the printer problems that you say are not yours to fix, despite my being unable to correct them by reverting to earlier driver revisions. Outside of these fora I only praise PMView. -- Mark

[Peter]

Also, I am shocked to hear you talking about stopping development of the OS/2-eCS version.

Read again. I did not say that. However, I have bills to pay as everyone else and a family to take care of. I can't afford to put paid work to the side in order to try to hunt down obscure problems in the OS/2 version.

I will try to keep the OS/2 current with the Windows version, but that's about all I can do. So far I have sold 2 copies of PMView for OS/2 this year.

[Peter]

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

Al,

Are you saying that 3.70 works?

That would seem strange, as v3.71 only has a two bugfixes that are not related to the File Open dialog at all.

"New" problems that occur after installing PMView are usually related to OS2.INI corruption (possibly made worse after WarpIN made changes to OS2.INI during installation). Are you regularly cleaning your INI files with IniMaint or a similar tool?

Also, check your setting of the "Use Workplace Shell APIs for copy/move/delete" in PMView's options notebook and read the on-line help for this setting. (This is very important if you don't do regular cleaning of your OS2.INI. Using the WPS API leaves file handles dangling).

[Peter]

Is it possible to set it to read a specifici number of directory levels?

PMView only reads one level down - this is done in order to be able to add the [+] to a directory (to visually show that it can be expanded).

If you turn off subdirectory scanning (which should be much faster), you will lose these [+] signs, but you can still double-click on a directory to expand it.

So if you know your directory structure it's definitely worthwhile to turn off sub directory scanning. However, if you're frequently exploring new unknown paths, the [+] is of course much needed.

[asavage]

Feb 8 2013 is the build date of v3.71. Continue reading the log and you will find the actual logging time

Nothing like displaying my lack of reading skills to the world

Are you saying that 3.70 works?

I had been planning to do multiple installations and try to find a version that worked "better", but it's taken me quite a bit of time to just get a decently repeatable testcase, so I haven't.

But, to answer your question: the FOC in versions prior to 3.71 could be counted on to go to 100% CPU utilization when reading from a remote drive about one in ten times (a rough estimate). It was often enough that for a long time I just avoided pointing to the FOC to a non-local drive. I've seen the problem for several years.

Lately, I've been doing a lot more work using PMV -- a lot of manual scanning of large materials. My workflow is to use TAME/SANE to scan to a default local directory, open the scan with PMV, rotate & crop, then save to remote drive. That worked fairly reliably, as the FOC would only read the remote directory once -- the first time I'd navigate there to save, and I found that I could avoid the 100% CPU problem that way.

When I went from 3.70 -> 3.71, that didn't seem to work as well: I was having the 100% CPU problem every day. I first noticed a very bad problem the very first time I installed 3.71, because the remote drive was not available, and the ini saves the last opened dir. So, I'd start 3.71, open FOC, and it would try to open a non-available drive, and it locked up there. I do not recall if it was a 100% CPU issue on that particular case. However, it was the same "locked up" with all three installations of 3.71. I backed all three out to 3.70; later, I figured out the trigger, rebooted the remote server, and reinstalled 3.71.

As long as the "last directory read" is available, the FOC does work reasonably well, as well as 3.70, but it does go to 100% CPU more easily than previous versions.

I've found a close-to-repeatable testcase here: if I have a filter of *.* and Thumbnail type of Icon or Mixed, I can usually get it to trigger if I read a certain directory over and over. It takes a lot of reads, but eventually it will trigger and the CPU will go 100%. On both boxes, different versions of OS/2, same local directories and with fewer than (55) files in each.

That makes it not a networking issue (as I'd thought it was for years), not a specific FP level issue, and not a "too many files to read" issue.

On the eCS box, I have TOP/WatchCat (or whatever it's called) installed by default, and I can kill PMV and resume using the box, although if I do that 3+ times other system problems crop up and I have to reboot that box. Since it's JFS, that's not a big deal: it's a fast reboot.

My scanner box is Warp4, does not have WatchCat/TOP installed, uses HPFS386 drives, and a reboot is nearly 15 minutes due to the slow mount of the drives (HPFS & HPFS386 take a very long time to mount large drives), so when the 100% CPU problems occurs, it severely interrupts my workflow.

I've finally gotten a couple of screenshots, one of each box, of the FOC and the CPU monitor.

(click on any image for larger)




I do have "/log=pmview.log" for both those boxes, but as PMV does not crash --it merely makes the systems unusable -- nothing useful is written to the logs. If there's a way of turning up the log level, I can do that.

I'm typing this on a third box on my network. I've just checked those two boxes whose screenshots I took and processed via CS3, and both are still at 100% CPU and have been for over an hour as I type this. As soon as I submit this post, I'll go reboot them both.

[Peter]

I've found a close-to-repeatable testcase here: if I have a filter of *.* and Thumbnail type of Icon or Mixed

Aha! I think I know what's going on! When you use a filter of * (or *.*) you make PMView examine all files, and attempt error-recovery on all files if a file format that PMView understands cannot be found.

It is possible that the directory contains a binary file that looks like a valid image format. PMView tries to process it, but the image size PMView reads (from what is believes looks like an image file, but really is not an image file) is so huge that it eats up all your RAM. The machine starts swapping, and voilà - you're at 100% CPU. Everything still "works" fine, but all the machine now does is swapping. Every application will be swapping and control is lost. However, nothing has crashed yet and all is still running "normally". Hence no error in the logs.

Now that you mention it, I have seen these lockups occur with Gigabyte-size ZIP files. My take on this was always "user error" - it was my own fault for leaving these huge files lying around and then use *.* in PMView. In retrospect I realize that I just asked for it to happen! I know what the files are. PMView does not, and goes to work in the hope that it can recover an image and show it to the user!

This DEFINITELY can happen. The solution to this would be to add more restrictions on file detection and maybe the possibility to disable the automatic file recovery feature in PMView. (The conundrum here is the "Bill Gates 640k" issue. What seems unreasonable big today may be normal 10 years from now).

It may also be a bug or unexpected behavior in one of the format detection mechanisms. In this case it needs to be fixed, of course!

In your situation above, I believe it's a problem that can be fixed easily (and needs to be fixed). See if you can pinpoint the offending file. Then copy it to another local directory and see if you can repeat the problem.

Or just copy all files to a different directory first, and once you can repeat the problem delete the files you copied one by one. When the problem goes away, you will know what the offending file is. A good place to start is to first look for files in excess of a certain size (say 50MB) and eliminate the chance that such a file is causing the problem. Yet another way to narrow down the selection is to try using filters like A* and then move on to B*, C* etc until the lockup occurs.

If you find the file that causes the lockup and e-mail it to me, I'll be sure to fix the problem! (Please contact me via e-mail first so I know to expect the file).

[asavage]

I'd love to be able to hand you a file that triggers this problem, but a single file does not do it. The cause is too subtle for me to determine, given the toolbox I own.

I hate to throw other variables into this, but I've just found another FOC oddity.

I have been able to trigger 100% CPU by using the <CurUp> and <CurDn> in the left pane of the FOC, and changing dirs quickly. I just noticed that if I do this fast enough, after maybe 20-50 directories the FOC "gives up" trying to create thumbnails. It says it's creating thumbnails, but never does.

Thumbnail Type is set to Mixed.

(click on any image for larger)

Correct behavior: "Cannot create thumbnail":


Incorrect behavior: "Creating thumbnail".


Back to the original problem: I copied all the files in that trouble directory to C:\TEMP1 and tried to trigger, but no joy. Then I went back to the trouble directory, and I'm still unable to reproduce. Arrgh. I'll work on it more, but I do not think this is a single-file problem.

These computers have 4Gb RAM installed (max'd out). I know that's a side issue WRT OS/2 and applications. I routinely open and rotate 130Mb PNM files under 1° with PMV on the scan box (11x17" color & 600dpi). It takes a while, but it always works. (Not so, on the identical hardware running XP with 4Mb RAM). When the boxes go to 100% CPU, I cannot operate them directly, but I can still access their HDDs via the LAN, and I intend to inspect the swap file this way. I am thinking that I will not find any swap file growth.

I'll post more when I have more info.

[Peter]

Al,

Do you have PMView configured to automatically create EA thumbnails? If so, PMView will QUEUE every directory you enter for thumbnail creation. The unexpected result you got above is probably because PMView was still busy working in one of the directories traversed earlier. (In order not to use too much resources, there is only one background thread that creates thumbnails. Files in the current directory are always moved first in the queue, but if the thumbnailer is stuck working on another directory then that does not help).

[Peter]

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