Revert back from 2017.9.4 to first 64Bit version

[ben]

Hi Mario,

is it possible to revert back from 2017.9.4 to the first 64Bit version you officially released (beta status)?
I would like to test the viewer.

When i first installed the 64Bit version, i was really impressed when i scrolled through images in the viewer.
I hardly saw the "Loading" message, even when scrolling fast with the mouse wheel.

Now, with 2017.9.4 i see the message every few seconds.
The load indicator shows the green symbols but still the loading message appears, sometimes for roughly a second.
I am showing jpgs only.

So, i would like to see what's the difference to the first 64 Bit version.

Win10, 8GB RAM
i5-6200U €2.4GHz
GeForce 945M

Logfile attached

Memory Consumption iMatch ~800MB
CPU Usage 35%

Thanks,
Ben

[Mario]

The only change in the Viewer is that the background cache loader now retries 3 times (instead of once) when it cannot load a file (with 100 ms wait time in-between) to work around situations where a user works in multi-image mode and WIC locks itself when multiple processes try to load the same file at the same time.

This change has no impact when you view only one file at a time, or when your system is fast enough to deliver the files without locking inside WIC.

[ben]

This change has no impact when you view only one file at a time, or when your system is fast enough to deliver the files without locking inside WIC.

I understand.

I haven't changed anything on my system, at least nothing that i am aware of.
Can i still try to revert back to an older version? I think the first 64Bit version came with 2017.8.2, right?

Ben

[Mario]

I don't support or test downgrades.
Do you have a log file in Debug mode from a session where you used the Viewer? It contains important info about Viewer performance, load-time per image etc.

[sinus]

Ben
have you also tried to set another value in the prefs for the viewer "How many files to preload .."
I have set this to 25 and it made a big positive difference for me.

[ben]

Do you have a log file in Debug mode

Yes, see my first post in this thread.

The loading message also appears for files, where the "preload seems to has been finished already" (green symbol shown in filmstrip).

have you also tried to set another value in the prefs for the viewer "How many files to preload .."

Yes, i did.
This made things much worse. I also tried 8 and 12 as setting.
But now less files get preloaded -> only 2-3 green symbols shown in filmstrip, while 13 thumbnails are shown.

[Mario]

Log file?

[ben]

??
Attached to my first post.

[Mario]

If this is the latest...

There is one warning about IMatch being unable to create a preview image for a MP4 file, and another one about invalid maker notes in one file. Nothing serious.

IMatch loads your files in about 0.5 to 0.7 seconds each.
That means that within 3 seconds it has pre-loaded 4 files. There should be no delay at all.

Do you use many overlays in the Viewer? Collections? Annotations? Category Panel? Dashboard?

[ben]

Do you use many overlays in the Viewer? Collections? Annotations? Category Panel? Dashboard?

I only display the timeline at the bottom, nothing else.
The viewer runs in full screen mode.
I am displaying one file at the time.


The loading message also appears when the file has already been loaded, according to the green small symbol.


I uploaded a new log-file.
One folder with 160 jpgs

[Mario]

I don't see anything unusual in this log file.
The images are  loaded from the cache in about 0.1 seconds which is more than OK. No warnings. No errors.

The only thing I notice is that the purge memory routine is called quite often.
How much memory does this computer have and how much memory the graphic card? What kind of graphic card?

[ben]

Graphics:
  Nvidia GeForce 945M
  2GB DDR3

System
  I5 6200U @2.3GHz
  8GB RAM DDR4
  iMatch,  the Database and all Pictures are stored on SSD
  Win 10 Home

[Mario]

Mhm, much better than mine....

[Mario]

Made some tests today. With a small and a large DB. Images JPEG and RAW, to 80 Megapixel files (8000 x 10,000 pixels each). No extended wait periods in the Viewer, even with multi-file dispaly. IMatch 64-bit.

[ben]

ok, thanks for trying.
I will try to reproduce it better.

[ben]

I have tried several things, always the same result:
  - Unsinstalled iMatch completely, removed the configfolders by hand (AppData folder etc.) and reinstalled -> 32 Bit and 64 Bit
  - created new database with only 300 images (all jpgs ~3-5MB)
  - CPU and RAM usage hardly goes ever over 50%


I tried to narrow down, when it happens:
It seems "loading ..." appears whenever i scroll to the next image AND imatch preloads an image.
So, when i switch to a new image that has already been preloaded (green symbol shown), but the viewer preloads another image in the background the "loading..." appears.
Seems like, preloading blocks displaying an image .

Ben

[Mario]

This seems to be pretty unique. I use the Viewer all week and I never see this effect Not even on my dusty ASUS Windows tablet with only 2GB RAM and Intel on-board graphic...
Not sure how to proceed.

[ben]

Not sure how to proceed.

Sigh. :-(
I hope we find an answer. Now, the great hw-acceleration and preloading mechanism are of no use on my system.

  - ask explicitly in the forum who else is having similar experiences
  - pause preloading when a new image is shown in the viewer
  - reinstall graphics-driver
  - reinstall win10 (uff, i hope not)
  - ...

[ben]

Hi Mario,

i might have found the reason:

I have one "data driven category" that was set to "auto update" and slowed down everything.
If i deactivate "auto update" for this category, then scrolling in the viewer is as fast as it used to be.
See the attachments for my settings.
I can live with this setup, so problem solved for me.


But it would be nice if you answered the following questions:
1) What is the reason, that data driven categories are recalculated during displaying images in the viewer? -> i have no panels active

2) What should happen if i set "the number of preloaded images for the viewer" to unequal 0? The filmstrip at the bottom always shows 1 (!) preloaded image. Whatever number between 1 and 25 i choose.

3) I think, displaying the new image (if already preloaded) should have the highest priority and shouldn't be delayed because of some background operations or preloading tasks. Don't you agree?


Thanks for your continuing efforts in this forum,

Ben

[Mario]

Data-driven categories are always re-calculated in the background. As well as the file history is updated (because you have viewed a file) and the "Viewer" collections are updated (because you have viewed a file).
But all that does usually not interfere with Windows WIC loading a JPEG image from disk into memory.

[ben]

But all that does usually not interfere with Windows WIC loading a JPEG image from disk into memory.

Maybe the word "usually" is the key ;-)
I can reproduce the behaviour by the mentioned data driven category.

[Mario]

The log file will tell you how long it takes for IMatch to calculate this category.
You use a tag and an potentially expensive category filter. But that should be only a few seconds...how are the pview... categories designed? Maybe this blocks the database for too long.

[ben]

how are the pview... categories designed?

- I keep all my images in D:\Bilder
  - There are 700 subfolders with ~22.000 images in total
  - Roughly 16.000 of those images belong to the top-level category "piview" -> manually added
  - The data-driven category "piview_folder" shows exactly the 16.000 files of "piview" again.
    Though, the files are grouped in a tree-structure that equals the folder structure on the harddrive.
    See my screenshots of the category-setting (above).

The log file will tell you how long it takes for IMatch to calculate this category.

Currently i am happy with the workaround "disabling auto update".
But if you are interested in finding the reason and fixing it, i am happy to help.
Maybe it just needs more digging like "the bug with the empty recent/top50 list in the keyword panel"

What else do you want me to do/check?

Ben

[Mario]

This may be a problem that happens only on one machine, with one database and in one specific context. Probably not worth to spend more time with that. Not unless other users run into similar issues.

I use very large databases (350,000+ files) with multiple data-driven categories, files taken with digital backs on Hassy with 12,000 x 8000 pixels and I have never seen this problem. Even data-driven categories with filters based on other categories calculate in a few second and don't block anything in the Viewer.

Search your log for #sl to find operations which took more than 5 seconds. Loading the database etc. is usually slower but all else should not. #BLOCK is also worth searching for because it means that one part of IMatch is blocking another for too long from accessing the database. That is usually caused by a too slow hard disk, or some virus checker etc. interfering and causing IMatch to perform non-optimal.

[ben]

Probably not worth to spend more time with that.

That's fine for me, since my workaround works.

Maybe as a last attempt, you could try my data-driven-category. Only takes a few minutes.
I can really reproduce it this way.



In case we open up this thread in the future again, this is what i found out so far (some aspects you mentioned have already been answered!!):

• slow hard drive -> no, images and database on SSD
• virus checker -> no, excluded the database and also uninstalled it
• iMatch left-overs after installations -> no, uninstalled iMatch and deleted the left-over folders and did a clean reinstall
• database related -> no, happens with a fresh database as well
• computer in general not too slow -> no, my laptop is better than Marios test computer (i4, 8GB RAM, dedicated graphics card), cpu/ram usage in general under 50%

Ben

[Mario]

What is the name of your data-driven category?
In both your log files I cannot finds entries for dd categories calculating very slow.
It is an expensive category (filtering on another category, detecting hierarchies) but in a modern PC it should stay well below the 5s threshold. Especially for such a small 25K files database. More like 0.5 seconds rather.