XnView Software

Hello Pierre,

I hope you are doing well. Congratulations on the new release of XnView MP.

Unfortunately, I have a rather strange bug to report. It's a bit complex, I tried my best to guide you through the required steps to reproduce it. Feel free to request more details and ask for my assistance (running a debug/test version).


Windows 10 Pro 64-bit, XnView MP v0.98.3 64-bit

This bug is available in many past releases of XnView MP, probably since the first release? I also tried solving this issue with a fresh install of XnView MP (64-bit installer). Comparing the settings of the fresh install with my regular setup of XnView MP helped me to identify the setting that causes the issue.


Current behaviour:
In browser mode, XnView MP generates a constant high CPU load and shows an empty progress bar with a varying width when certain conditions are met (described in the next section).


How to reproduce:
The following settings must be met to trigger the bug:

• In [Browser > Filelist > Custom filter] check 'visible' for 'Folders'
• In [Browser > Filelist > Custom filter] uncheck 'visible' for 'All other files'

The setting of the other filelist items does not affect the issue.


In Browser mode enter into a folder that meets the following conditions:

• the folder contains more images than XMP can display icons on screen at a time
• the folder contains at least one subfolder represented by a folder icon in the listing

The folder content is read to generate the file listing, a progress bar visualizes the process. On completion, the progress bar is removed.

Now browse the folder by [Cursor-Down] or [Page-Down] key. When a new set of icons needs to be drawn on the screen, the progress bar reappears and a constant high CPU load is generated. The progress bar remains empty (the bar never fills) and its width changes depending on the highlighted image.

The empty progress bar and the constant high CPU load disappear only when highlighting a subfolder icon in the file list once. From that moment the file list can be browsed without the described symptoms. However, pressing [F5] to reread the folder has the issue reappear.


This bug does not occur when one or both of the following conditions is met:

• All icons of the file listing (images/folders) can be displayed on one screen (no scrolling required)
• The file listing does not contain any subfolders

Setting 'All other files' to 'visible' in [Browser > Filelist > Custom filter] prevents this bug from appearing, but strangely this then affects the 'Add new files to end of list' function like follows:

When in Fullscreen or View mode, save a currently viewed image to a new file using the same filename appended by any letter (test.jpg > testa.jpg). The new file is always added to the end of the file list, regardless of the setting 'Add new files to end of list' en- or disabled.


Expected behavior:

• XnView MP should not generate any load on the CPU once the creation of the filelist for browser mode is completed
• No empty progress bar with varying widths should occur
• 'Add new files to end of list' should not be affected by 'All other files' of [Browser > Filelist > Custom filter]

Hello Pierre,

I posted this bug report three months ago and it makes me wonder why I haven't received any response yet. If you cannot or don't want to address this issue for any reason, that's fine with me. It is your free decision where and when to invest your valuable time for development and/or bug fixing and I respect that.

At least be so kind to let me (and the other interested users; this thread has more than 900 views already!) know, what's your take on this.

This bug actually sounds a lot like the bug I reported a while back (viewtopic.php?f=62&t=41180), albeit with a more detailed explanation (I wasn't 100% certain on what was causing the bug at the time, which is why my attempt at explaining how to execute the bug was kinda vague).

For me though, both folders and all other files set to visible, and this bug still occurs. Also, the variable width progress bars are still present when the filelist is being created. Not sure what's going on there, perhaps that is an indicator for if the bug is present?

sorry about my delay, but i need more investigation, i can't reproduce...

Hello Pierre,

I hope you are doing well and are in good health.

I just downloaded your latest release of XnViewMP v1.0 and tried it out for a short while already. I'm quite happy to inform you that the issue I reported above appears to be fixed. I hope I didn't get excited too soon and the bug is squashed for good.

Since you wrote that you can't reproduce the issue I suppose you probably don't know what actually fixed it? Anyhow, thank you for another great release of XnViewMP with lots of fixes, improvements, and quality-of-life tweaks under the hood.

With my best regards and wishes to France.