![]() |
![]() |
![]()
Post
#1
|
|
![]() Forum Member Group: Members Posts: 100 Joined: 6-August 00 From: Duvall, Washington USA Member No.: 28 ![]() |
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. -------------------- |
|
|
![]() |
![]()
Post
#2
|
|
Forum Member Group: Members Posts: 11 Joined: 20-January 06 Member No.: 205 ![]() |
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 |
|
|
![]()
Post
#3
|
|
![]() Forum Member Group: Admin Posts: 672 Joined: 14-March 00 From: Wilmington, North Carolina Member No.: 3 ![]() |
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. -------------------- Peter Nielsen (peter@pmview.com) "If you can dream it, you can do it" JFK.
|
|
|
![]()
Post
#4
|
|
![]() Forum Member Group: Members Posts: 100 Joined: 6-August 00 From: Duvall, Washington USA Member No.: 28 ![]() |
QUOTE 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 ![]() QUOTE 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. -------------------- |
|
|
![]() ![]() |
Lo-Fi Version | Time is now: 24th September 2024 - 01:50 AM |