Performance of rescan on pdf and new added filetype

[meyersoft]

I am using imatch 3 for image organisation and would like to extend the use on imatch 5 and all its new possibilities.
So I was generating a test database with music notation files (pdf and finale mus files, newly added filetype).
I recently tried to add a folder with ~2000 files.
The PC is now busy rescanning for several hours....
In the debug log file, I observed some strange entries:
10.21 22:13:31+    0 [0EEC] 01  W>     EUQH::Load(1) failed for D:\Noten\Hallelujah_Cohen_Orig_Partitur.mus (8/'Nicht implementiert') with 0 x 0  'IMEngineUpdateQueue.cpp(478)'
10.21 22:13:36+    0 [1E68] 10  I>     EUQH::Load(1) of D:\Noten\Hallelujah_sing_a_Song_Querfloete2_scan.pdf with 1000 x 1000 (O: 1000 x 1000) in 84203ms
There are several similar entries.
The first seems to indicate that the added filetype *.mus has a problem.
The second is on a pdf, generated with some freepdf tool. If a single file load takes 84 secs, I do not wonder that the whole rescan of 2000 files takes hours....

Mario, I would be glad to help improve performance by providing additional information.
What information do you need?

[Richard]

In most cases Mario would like to see the log file from any session in question. The best log is one where it is set to the Debug mode.

[Mario]

The first message just tells you that Windows was unable to produce a thumbnail for the .mus file (whatever that is).

The 85 seconds (!) required to create a thumbnail is typical for the crappy Adobe Acrobat PDF component installed in Windows. I have seen this Adobe component take 2 GB of RAM and two minutes to extract a thumbnail for a PDF generated in Photoshop. The FastPictureViewer PDF WIC codec does the same in less than one second.

Sometimes the Adobe component is fast, and sometimes it utterly fails. This is not an IMatch problem, though.

When IMatch has no built-in reader for a given file format (PDF, in this case) it asks Windows to produce a thumbnail/read a preview. Windows itself relies on the component installed by Adobe when you install Acrobat Reader or Acrobat. And this component is utter crap and really a shame for Adobe.

The best solution is to install a PDF WIC codec. IMatch automatically uses it instead of the Windows thumbnail API.

[meyersoft]

Richard, Mario, thanks for your answers.

I don't really care for the *.mus thumbnails - if the error only says it cannot produce it, that's fine.
Installing a pdf WIC codec seems to be a good idea. I had a brief look and only found non-free codecs that have trial periods. Did I miss free codecs?

[meyersoft]

In addition, I would even not care about pdf thumbnails if that would speed up things.
But I think there is no way to set this up, is it?

[Mario]

But I think there is no way to set this up, is it?

No. There is no per-file format "Don't try to generate thumbnail" option.
It would be better if Adobe could be bothered to ship better quality, even if Acrobat Reader is free. This problem is known for years but Adobe rather spends money for pulling their users into subscription based, pay per month, schemes that fixing bugs which are known for years.

You can un-install Acrobat Reader. Windows will then no longer find and use the Adobe Acrobat component for thumbnail generation. There are plenty of free PDF readers I think. Or pay a few bucks for a PDF WIC codec.