Slow/paused startup on v1.10.3

[Foxyrick]

This didn't happen on 1.10.1. When I start XNViewMP, the main screen comes up fully, just as it always has (folders are shown etc), but it cannot be interacted with for several seconds; about five or more. It's frozen up for that long. I checked 1.10.1 again and it does not happen there. This only seems to happen the first time XNViewMP is started after the PC is restarted, but it happens every time in that case. Subsequent starts of XNViewMP do not suffer the freeze. At least for some time; I think it has happened again some hours later without the PC being restarted in between.

Two thoughts:
1) I'm usually browsing a network share although that's not usually a problem, nothing has changed here, and version 1.10.1 is OK.
2) I have a printer which I've noticed some programs try to 'check' or something when they start, and those programs freeze for several seconds to half a minute if the printer is offline. Probably a driver issue (it's a strange printer which is tricky to get to talk). Again though, XNViewMP 1.10.1 has no problem.

The above might be nothing to do with it, but there is certainly a difference in behaviour between 1.10.1 and .3. When I have time I'll try to investigate further to see if I can narrow a cause down.

Edit: I take some of the above back - I just started XNViewMP again, having closed it while I wrote the above (probably 15 minutes between starts). It froze up again for about ten seconds. Everything looked right; folders and files were shown etc, but it was just frozen.

[xnview]

and in 1.9.10? You have the problem even if you start on internal drive? do you use theme?
if you change debug=2 in your settings, where do you have the lock in the logs?

[Foxyrick]

Quick reply so you know I've not gone away...

The issue doesn't happen on 1.9.10; I installed it to check (having removed 1.10.3).

I don't use a theme.

I then reinstalled 1.10.3, but I cleared my settings folder (%AppData%\Roaming\XnViewMP) first (I saved the files for later). Ran once to get past the initial setup dialog, rebooted, then ran again. The freeze did not happen when starting XNViewMP by right clicking on and browsing a network share from Explorer.

Then I replaced my previous settings back into the settings folder, did the same as above, and the freeze happened again for about ten seconds.

I'll check local browsing and setting debug=2 when I get chance to play again later.

(I could try just re-creating my settings instead of copying them back, that might clear whatever is happening, but more interesting I think to see if we can find out why it's happening).

[xnview]

Then I replaced my previous settings back into the settings folder, did the same as above, and the freeze happened again for about ten seconds.

I'll check local browsing and setting debug=2 when I get chance to play again later.

(I could try just re-creating my settings instead of copying them back, that might clear whatever is happening, but more interesting I think to see if we can find out why it's happening).

Please tell me if you find the problem?

[Foxyrick]

I've been trying to get some consistency in the freeze... I can't. It seems quite random. Sometimes it doesn't freeze, sometimes it does for anything from a few seconds to more than ten seconds. The freeze is a complete lock-up; XNViewMP appears to be doing nothing and is completely unresponsive when it happens.

The log window I watch from setting debug=2 is just as inconsistent. So far it hasn't stopped anywhere near the same thing twice; it's very different every time. I started keeping copies but I don't think they are useful.

I always start XNViewMP by right-clicking a folder in my file manager (Directory Opus but I don't think that's anything to do with it) and selecting Browse with XNViewMP. It does not seem to matter if I browse a folder that is already fully catalogued, or one with a few new images in. The freeze is still random.

If I get time over the next few days I'll copy my database to the local HDD and try that, instead of keeping the database on the NAS. Just in case that matters.

I still use 1.10.1 installed on another PC, using the same NAS database and I use XNViewMP exactly the same way on there, and that has never done the freeze.

I'll keep you updated with anything I find out.

[xnview]

I always start XNViewMP by right-clicking a folder in my file manager (Directory Opus but I don't think that's anything to do with it) and selecting Browse with XNViewMP. It does not seem to matter if I browse a folder that is already fully catalogued, or one with a few new images in. The freeze is still random.

So the lock is always when starting the browser? Windows 11?

[Foxyrick]

Windows 10 LTSC 21H2.

I just tried starting from the desktop shortcut instead; I've just turned on the PC. XNView froze up again. About ten seconds. When I click anywhere in the window, after a few seconds I get Windows' swirling 'busy' cursor, the X in the top-right corner to close XNView turns red, and "not responding" is shown in the title bar. Then when it un-freezes it all goes back to normal.

I was watching the log window and it froze at one of the several lines of "### ThumbLoader Thread :: setFirstItemToLoad".

After it un-froze, I noticed this in the log:

### ThumbLoaderThread :: setFirstItemToLoad
### ThumbLoaderThread :: setFirstItemToLoad ok
## updateCount ===> 13641ms
## updateCount ===> 13641ms ok

If that 13641ms is a time, it's about right for how long XNView was frozen. The folder XNView started in was only small and obviously was the last used folder, so fully catalogued already. I've not noticed any variation in this issue depending on the folder size where I start. Yet, anyway.

I have a lot of things to do today (need to quickly re-write a big program myself, then fit a new ••• SPAM ••• tap, lol) but I'll try to copy my 3.5GB XNView database to the local HDD on this PC and run like that. Try to take the NAS out of the equation and see if it helps.

[xnview]

## updateCount ===> 13641ms
## updateCount ===> 13641ms ok

The problem is here! The database is stored on your NAS?
With 1.10.1, "## updateCount ===>" show always a lower time?

[Foxyrick]

That long update count time is common to all the logs I saved when it froze, although those lines appear in different places (not always following the ThumbLoaderThread lines). When it doesn't freeze (noticeably) the time is much shorter at around 1000ms or less.

I just tested 1.10.1 on the other PC, first changing the .ini to make it start in the same folder and set debug=2. To my great surprise it froze too, for about the same 13000ms.

That's the first time I've seen 1.10.1 freeze. I've only noticed this since updating to 1.10.3 on this PC.

I've installed 1.9.10 on the other PC and I'll try with that for a while. However...

...so far, starting XNView again on either PC, whatever the version, does not show the freeze. It almost feels like a caching issue. ADDED: I've restarted the other PC a few times, with 1.9.10 on it, and XNView starts quickly every time. Not even a hint of a freeze.

Can I ask... is that UpdateCount line to do with XNView reading the database, or the folder of images? If it's the database then moving that to the local PC might be diagnostic.

P.s. If this turns out to be a problem with my NAS, and nothing to do with the update (just coincidental timing) I'll be very sorry.

[xnview]

Can I ask... is that UpdateCount line to do with XNView reading the database, or the folder of images? If it's the database then moving that to the local PC might be diagnostic.

It's a request on the database. In 1.9.10, there is no such request (count in catalog filter). If the database is local, database access is faster.
Which file size for xnview.db?

[Foxyrick]

xnview.db is 1.6GB.

Accessing the database locally on this PC is certainly faster (10's of ms instead of hundreds or thousands, or 13000!). I noticed that 1.9.10 starts up more quickly (i.e. can be interacted with more quickly) than 1.10.3, when using the NAS even when there isn't a long freeze; and 1.9.10 never freezes.

It's completely expected that it would be faster on a local PC (with fast SSD!) than going to the NAS of course.

The question then is why is it sometimes <1000ms (which I could live with), and sometimes >13000ms for the same startup folder, and what can be done about that?

My NAS isn't heavily used. There's only me using it and it sits there idle most of the time. There's no HDD sleep or anything like that set on it and everything else here works as fast as I expect it to (loading big files into Blender or Photoshop for instance).

[xnview]

i've sent you a PM

[Foxyrick]

That test version starts perfectly, like 1.9 did. It's noticeably quicker to be able to interact with it than 1.10.3; practically instant again.

[xnview]

That test version starts perfectly, like 1.9 did. It's noticeably quicker to be able to interact with it than 1.10.3; practically instant again.

count request is disabled in this build... Is it possible to send us the xnview.db?

[Foxyrick]

Uploading now, I'll PM you a link when it's done