Monitoring surprisingly slow (or fast) [#5520]

[neFAST]

I always thought that the "monitoring of file" step was slow by nature but today I disovered something:
If my selected view is empty (or the now playing one) it is 100 times faster.

Is there nay explanation ? or some improvement that could be done ?

[Peke]

Can you make two debug logs as described here http://www.mediamonkey.com/forum/viewto ... ?f=1&t=341 one that shows slowness and one that show 100 times faster?

That would help us to locate the issue.

[neFAST]

In Debug mode and with Dbgview I only observed a factor 2. In any case here are the logs: http://pi.aime.free.fr/files/logs.rar
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

[PetrCBR]

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

[neFAST]

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)

[Teknojnky]

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.

[neFAST]

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

[dbdog]

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.

[rusty]

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

-Rusty

[Mixta]

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!

[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).

[Mixta]

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 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!

[Lowlander]

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

[Mixta]

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

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

[Lowlander]

I dont manually edit files inside or outside MM while monitoring process is proceeding or at any other time for the past few weeks.

You may not, but others may do so.

i can close MM, start MM again 1 moment later, and monitoring process is starting again

As you enabled Startup Monitoring it is expected that it starts each time you start MediaMonkey. I personally use manual scanning instead.