Initial scan taking too long [#21916]

[MiPi]

The speed is slowed down most probably because you have a lot of artworks in external files, and new versions check these external files on rescan. But thanks for the log, I think I have idea how to speed it up (besides option to switch this check completely off), will try soon.

[MiPi]

Fixed, in the next version rescans should be significantly faster even for libraries with many linked external artworks.

[Peke]

The speed is slowed down most probably because you have a lot of artworks in external files, and new versions check these external files on rescan. But thanks for the log, I think I have idea how to speed it up (besides option to switch this check completely off), will try soon.

A zip-file with my config-file and logs from rescans with build 3194 and 3203
https://1drv.ms/u/c/bae5db40241ac824/IQ ... k?e=lp7FP9

I use a SSD PCIe 5 as a bootdrive and a raid-drive for data, maybe thats the reason the scan with build 3194 is that fast.

Just wanted to confirm that external Artworks slows down rescan in 3203.

For me on 80k of tracks on NAS it takes average <5min, but I have 95% of tracks with Artwork saved to tags.

Wanted to thank you for persistence and good catch.

NOTE: This rescan check is added when we got number of reports that Album art fall back to default MM image when Art cache is deleted and external links gets not available.

[ruebennase56]

Fixed, in the next version rescans should be significantly faster even for libraries with many linked external artworks.

Build 3206 is as slow as build 3203.

[MiPi]

ruebennase56: and do you mean really rescan of previously scanned files? The fix was related to files already present in DB, which were not changed since then, and even then slowed down rescan a lot.

Btw. it seems scanning of (new) video files is somehow slow, analyzing.

[MiPi]

There is really something odd in the last builds, causing slower scanning, inserted to bug database: https://www.ventismedia.com/mantis/view.php?id=21954

[MiPi]

Build 3206 is as slow as build 3203.

Just noticed the reason - you have "Analyze files for duplicates" in Library options set ON! This option causes, that MM has to compute checksum from the contents of each file and it needs significantly more time, as it reads a lot more data for every file. Try to uncheck it and it will be fast again I bet.

[ruebennase56]

Build 3206 is as slow as build 3203.

Just noticed the reason - you have "Analyze files for duplicates" in Library options set ON! This option causes, that MM has to compute checksum from the contents of each file and it needs significantly more time, as it reads a lot more data for every file. Try to uncheck it and it will be fast again I bet.

Even with the changes in options a rescan still takes about 45min :'(

[MiPi]

Even with the changes in options a rescan still takes about 45min :'(

Do you have DbgView running? Sending debug messages also slow things down a lot.
Then in case you have checked option "Update file info from tags when rescanning files" you should have also "Only for files with changed timestamp or size" in Options - Library, otherwise it scans all files again and again.

[ruebennase56]

Even with the changes in options a rescan still takes about 45min :'(

Do you have DbgView running? Sending debug messages also slow things down a lot.
Then in case you have checked option "Update file info from tags when rescanning files" you should have also "Only for files with changed timestamp or size" in Options - Library, otherwise it scans all files again and again.

That's a screenshot of my prefs.
https://1drv.ms/i/c/bae5db40241ac824/IQ ... 4?e=5kidzx

[Peke]

That's a screenshot of my prefs.
https://1drv.ms/i/c/bae5db40241ac824/IQ ... 4?e=5kidzx

I am not sure what to tell you, I spent 5h+ testing and measuring MM behavior. You can see results at https://www.ventismedia.com/mantis/view ... 954#c80463 you were right there was an issue with initial MM 2024.2.1 builds but it was improved a lot in 3208 build. There must be something on your system that is causing issues. Simply said as we do not scan same files or same file formats. It is possible that there is a bug in MM reading some files, but unfortunately we can't catch it. If there is anything that can narrow things up or explain please let us know and we will gladly investigate.

[rusty]

Hi Ruebennase56,

We're getting very close to releasing 2024.2.1 but I see that we never closed the loop on this.
Can you tell me, when you're testing the current build vs 3194 are you installing the current build on top of 3194 (or vice versa) OR are you doing to separate installations (which could inadvertently result in configuration differences between the 2 installations)?

Thanks!

-Rusty

[ruebennase56]

I always install the new builds on top of the old ones. (no change in speed with build 3209)

[Peke]

I always install the new builds on top of the old ones. (no change in speed with build 3209)

Can you test with Vanilla 3209 portable install (You can skip all First start Wizards) and measure scan time. Beside what @rusty said, this issue one of rare few issues still potentially blocking release of 2024.2.1 stable build. Being us we do not like when KNOWN issue may slip in stable build. That said we would like to get to bottom of it. I Sent you PM.

[MiPi]

ruebennase56: Can you please generate new debug log for me with rescan of files (on your current installation, where you experience slow rescans - i.e. scans of files already present in your DB). Note, that with DbgView running you cannot measure time, because logging slows things down a lot. Test on some folder with many files, where there was ideally no change, so rescan should be very fast. Currently I am slightly lost and have no idea, what should slow things down for you in such situation. Thanks.