XnView MP happens to hang 50% CPU process after closing

[secarica]

From time to time it happens that XnView MP remains somehow locked as a background process, consuming exactly 50% CPU processor in task manager.

I am aware of the moment when this happens because I am on a laptop with Intel CPU that normally keeps its clock speed at 1GHz with the fan running slow and silent and when XnView MP process locks then the CPU goes to 2GHz with the fan going very fast and noisy. After killing the process the fan returns back to silent in 5-7 seconds.

Unfortunately I cannot give a pattern of what are the conditions of this to happen. I am on Windows Vista Ultimate 64 bit, running with UAC off. I am using XnView only for viewing images (i.e. not in browsing mode). Currently version 0.68, but was the same with the version available in March this year (cannot remember before that).

Ever encountered such thing ?

[xnview]

so you are in view mode, and view some picture files in fullscreen mode, that's all?

[secarica]

No, not in fullscreen (I rarely use fullscreen). Happened right now: just open a picture from a folder (this time containing 146 .jpg images mixed with 26 .mp4 video files, but this is just random situation), quickly scrolled forth and back several times searching for a particular picture, ESC -> image window closed, processor gone 2 GHz, had to kill manually the XnView process. Except that I cannot tell if the processor gone full speed while the image was still open, or just after the ESC command.

[m.Th.]

50% CPU?

Perhaps you have a dual core CPU and one of them is used 100%?

Perhaps the program freezes when it is trying to build a certain thumbnail for a certain (video) file?

[secarica]

True, it's dual core, never think in this regard about that 50%.

But thumbnail ?
1. Why would try this in viewer mode ?
2. .mp4 is not on its viewable file types, at least all video category is unchecked in settings and this is also the actual behavior: when scrolling through pictures it never tries to open video files and by entering in browser mode it never shows video files in those thumbnails (it simply skips).

[m.Th.]

True, it's dual core, never think in this regard about that 50%.

But thumbnail ?
1. Why would try this in viewer mode ?

The background thread which builds the thumbs works till it finishes the folder.

2. .mp4 is not on its viewable file types, at least all video category is unchecked in settings and this is also the actual behavior: when scrolling through pictures it never tries to open video files and by entering in browser mode it never shows video files in those thumbnails (it simply skips).

Hummm....

When you say "after closing' you mean after closing XnView MP or after closing View mode only?

Btw, are you admin on your laptop/storage where the data/config files are written?

[secarica]

The background thread which builds the thumbs works till it finishes the folder.

Myes, could be, only that I was expecting that it never tries to build thumbnails when in viewer mode (why should bother with something I never see ?)

When you say "after closing' you mean after closing XnView MP or after closing View mode only?

I only "close" via escape key, not by clicking on window's X corner.

Edit: I don't know how to close view mode only but keep XnView MP open. On my computer the program only opens when I double click an image, I never open the program directly.

Btw, are you admin on your laptop/storage where the data/config files are written?

Yes, admin. The user data is stored in C:\Users\secarica\AppData\Roaming\XnViewMP which is fully accessible regardless I am admin or not. I also deleted all .db files there, no difference.

But, hmm, maybe here is a clue: I kept now open the task manager to see "live" the process behaviour. When scrolling (with the mouse wheel, probably scroll is not the right word here) forward and backward very quick, i.e. passing through several images in short time (which is the way I do often), the CPU goes as high as 97. When I stop scrolling, the CPU lowers anywhere between 00 and 15. The problem seems to occur when I hit ESC before the CPU relaxes, that is during the time XnView (probably) tries to catch some next image for caching. Could be there is a thread (call, subroutine) that, when returning, no longer founds its parent initiator (because I closed it) and remains perplexed ? (just sitting there and consuming in vain 1 CPU core)

[m.Th.]

I don't know how to close view mode only but keep XnView MP open.

You should click on red 'X' on the tab above the photo. See bellow:

XnView-Tabs.jpg (19.52 KiB) Viewed 1990 times

XnView can open multiple files at once which it organizes in tabs. You can close the tabs by clicking on the red 'X' in the Right part of the tab. Also you can switch between tabs by clicking on them. There are some special tabs - one of them (pictured above) is the Browser tab which show the entire folder as thumbnails in a very convenient manner.

But, hmm, maybe here is a clue: I kept now open the task manager to see "live" the process behaviour. When scrolling (with the mouse wheel, probably scroll is not the right word here) forward and backward very quick, i.e. passing through several images in short time (which is the way I do often), the CPU goes as high as 97. When I stop scrolling, the CPU lowers anywhere between 00 and 15. The problem seems to occur when I hit ESC before the CPU relaxes, that is during the time XnView (probably) tries to catch some next image for caching. Could be there is a thread (call, subroutine) that, when returning, no longer founds its parent initiator (because I closed it) and remains perplexed ? (just sitting there and consuming in vain 1 CPU core)

Quite possible. A spanned/forked (sub)process which isn't cleaned up when the program closes. A "thing" (thread etc.) which waits a stop signal - which will never come.

[secarica]

I don't know how to close view mode only but keep XnView MP open.

You should click on red 'X' on the tab above the photo.

Useless in this context, because I keep "Closing last tab exits XnView" checked. I even hope that one day a "hide tab if only one tab" option to be implemented, something already present in the non-MP version (but not such a dramatic thing without that option, though)

Quite possible. A spanned/forked (sub)process which isn't cleaned up when the program closes. A "thing" (thread etc.) which waits a stop signal - which will never come.

Perhaps closer to the origin of the issue ? I unchecked "Read one image ahead" and so far the problem no longer appeared (but I need to test this variant more intensively).

[m.Th.]

Useless in this context, because I keep "Closing last tab exits XnView" checked. I even hope that one day a "hide tab if only one tab" option to be implemented, something already present in the non-MP version (but not such a dramatic thing without that option, though)

...in this case, in order to open the browser, just click on the leftmost button on the toolbar. In my screenshot several posts above is the 1st button from the left, the one with some yellow folders on it.

WRT main topic of the thread, please report back if unchecking the read-ahead is solving the problem. (I think it does, but we need your feedback)

[secarica]

Useless in this context, because I keep "Closing last tab exits XnView" checked.

...in this case, in order to open the browser, just click on the leftmost button on the toolbar. In my screenshot several posts above is the 1st button from the left, the one with some yellow folders on it.

I tried that (with "Read one image ahead" reactivated): closing the tab of the viewing image (not the browser) the problem persists and the application then simply hangs completely (mouse cursor over the application window remains in rotating waiting icon and the window itself turns light gray (inactive) – I have to kill the task).

If, before closing anything, I give the chance for the processes to relax (that is, waiting a bit after going back and forth through images and before closing anything), the problem never occurs.

I also found a way to reproduce the problem quicker, that is using PAGE UP/PAGE DOWN keys instead of the mouse wheel (keep pressing one or the other), in a folder with > 1000 .jpg images, where almost all file sizes are between 1M and 2M and almost all image sizes are either 4000×3000 pixels (if 4:3) or 4000×2248 pixels (if 16:9).

WRT main topic of the thread, please report back if unchecking the read-ahead is solving the problem. (I think it does, but we need your feedback)

With "Read one image ahead" unchecked I am unable to reproduce this thing, so I think it can be considered confirmed already – at least on my system.

[xnview]

WRT main topic of the thread, please report back if unchecking the read-ahead is solving the problem. (I think it does, but we need your feedback)

With "Read one image ahead" unchecked I am unable to reproduce this thing, so I think it can be considered confirmed already – at least on my system.

and you have only jpeg files??

[secarica]

and you have only jpeg files??

In that folder, yes. Almost all there are taken with my Nokia N8 (but this is less important, it happens the same, although more rarely, on another one containing 1600×1200 pixels images taken with an older Sony Cybershot).

[xnview]

and you have only jpeg files??

In that folder, yes. Almost all there are taken with my Nokia N8 (but this is less important, it happens the same, although more rarely, on another one containing 1600×1200 pixels images taken with an older Sony Cybershot).

and the loading of a jpeg is quick?

[secarica]

Don't know what means "quick". In a folder with 1311 .jpg images from Nokia N8 (454 being 4000×3000 and the rest 4000×2248), from opening first -> keep pressing PAGE DOWN -> to last image displayed it takes 2 minutes and 10 seconds with "Read one image ahead" OFF and 2 minutes and 15 seconds with "Read one image ahead" ON. During this time the processor works at its maximum frequency (2GHz).

Graphics chipset is ATI Mobility Radeon X1600 with 256MB RAM if that matters.