How it scans during monitoring depends on your scan settings under Tools > Options > Library.

[quote="Lowlander"]As you enabled Startup Monitoring it is expected that it starts each time you start MediaMonkey. I personally use manual scanning instead.[/quote]

Adopted! manual scanning it is ;)
But i still don't understand why monitoring process takes that much time, and even more or less depending on how big the list currently in viewed is. Other media player do the same or similar task in less time. Its obvious that MM does not just search for new and changed files (modified date) in specified directories but more... - every time monitoring is triggered. Especially in the case of an unchanged media library its very annoying, i hope a developer reads this and rethinks the monitoring process!

thanks, bye

[quote="Mixta"]I dont manually edit files inside or outside MM while monitoring process is proceeding or at any other time for the past few weeks.[/quote]You may not, but others may do so.

[quote="Mixta"]i can close MM, start MM again 1 moment later, and monitoring process is starting again[/quote]As you enabled Startup Monitoring it is expected that it starts each time you start MediaMonkey. I personally use manual scanning instead.

[quote="Lowlander"]While MM is monitoring the user can edit files in MM. The monitored files may have changed outside of MM.[/quote]
i dont manually edit files inside or outside MM while monitoring process is proceeding or at any other time for the past few weeks.
And no new files either, thus e.g. no auto volume leveling is triggered.
And no other software is changing any music file in background.
i can close MM, start MM again 1 moment later, and monitoring process is starting again, including the described performance issue with big lists eg music node.

i get the feeling that i am the only one who noticed this, or maybe everybody else accepted it slow speed during monitoring process after startup.
I recently switched to MM from musicbee, startup and monitoring (searching for any kind of change inside my music directory) never took that long...
i am quite disappointed

While MM is monitoring the user can edit files in MM. The monitored files may have changed outside of MM.

[quote="Lowlander"]Because you may be editing which means you are dealing with 2 states (the new edit in the file and the new edit in the database).[/quote]
It only says monitoring everytime i start it (startup configuration). Thus no, i dont think so, cause it would mean that mediamonkey edits my entire library evertime i start!

Because you may be editing which means you are dealing with 2 states (the new edit in the file and the new edit in the database).

It was not fixed, probably just reduced the negative effect. With version 4.1.8.1751 the list view is still updating during monitoring, which means that it is monitoring far slower when i select a big list or a node like "music". why updating view during monitoring at all? just display the previous state and update the view after monitoring has been completed!

Thanks. Tracked at:
http://www.ventismedia.com/mantis/view.php?id=5520

-Rusty

I've experienced the same behavior. When I'm showing lots of files in my track browser (e.g. library node) monitoring is super slow. When I navigate to some smaller set of files, say a playlist with 100 files, it speeds up dramatically (100 times would be my rough quess). I'd imagine the amount of slow down would be relative to how many files one has in the library.

@Teknojnky: actually when I select the now playing view, it's faster. And not the opposite.

mm saves the now playing list as m3u, not in the library, so whenever you start MM and it loads the m3u list it has to read both the m3u file and find the files in the database (to get play count/history/etc).

If you have a huge now playing list, then yes it will take alot of processing on startup just to read the now playing.

If you are trying to get a random play of your entire library, you are much better off using an auto-dj and limit now playing to 100 tracks or less.

I don't know for sure why mm still uses the m3u for now playing, loading it from the database is much faster. I assume it is for winamp/plugin compatibility or some such.

After a few tests, the slowness has no direct link to the display of the track browser and the album details.
It's related to the fact that the list display a few tracks (now playing) or lots of them (full library)

We're planning some improvements in track browser for future.

In Debug mode and with Dbgview I only observed a factor 2. In any case here are the logs: [url]http://pi.aime.free.fr/files/logs.rar[/url]
I benchmarked the release version: 1m49sec vs 28min for ~30.000 tracks

Step to reproduce:
(preliminary, set your folder to be monitored on MM startup, show "track browser" (3 panes) and show "album art with details")
a. start MM 3.1.0.1235 release
b. click on "now playing" view in the left tree
c. wait for the monitoring to be over
d. close MM

then
e. start MM 3.1.0.1235 release
d. click on "artist & album artist" in the left tree (the track browser will populate)
f. wait for the monitoring to be over
g. close MM