[1460+] MM4 performance with large library sucks

[Dreadlau]

I would expect the grid to be updated on each song. But only if there is something updated in the file scanned or when it's a new file being added.

Is that really so important that it justifies giving the impression to 90% of the users that Mediamonkey is slow?
Cause I doubt that more then 10% of the users are aware that they need to switch to an empty node to get a decent scanning time.

[vpsaxman]

I would expect the grid to be updated on each song. But only if there is something updated in the file scanned or when it's a new file being added.

Is that really so important that it justifies giving the impression to 90% of the users that Mediamonkey is slow?
Cause I doubt that more then 10% of the users are aware that they need to switch to an empty node to get a decent scanning time.

[Peke]

Switching to Now Playing Node While scanning is always good solution.

[robojock]

Switching to Now Playing Node While scanning is always good solution.

Since when? MM4? Definitely not from mm3 days

@ Peke, i fell in love with mm cause of the way it could handle a large music collection, with mm4, the first builds performance was good but mm was buggy. Now its packed with features and getting stable, which is nice, but the performance its heading in direction of itunes/WMP/ and all similar players i have tried over the years, which is crap and slow.

Is mm4 the "vista" of mediamonkeys?

[PetrCBR]

robojock, don't forget we're still in alpha stage. Also i've made some improvements for a next build so i'm looking forward for a feedback.

[Peke]

Petr is right. MM4 is still in Alpha stage so when we hammer down all possible risks. MM Speed will be top priority before release.

Too much things are changed in MM Library Structure and query got complicated a lot. With each build of MM we slip several optimization fixes.

BTW It was always like that just it was not so obvious when only Music is handled and there was no Album Art Views, Thumbnail creations, ... I also have 100k+ library so guess would I like to get MM faster?

[robojock]

I've been reading this on mantis, scanning is one of my issues, doing a scan now, mm4 reads a few files "waits" a bit, then scans again, waits a bit more, then it scans fast through a few files and waits a bit and thats how it goes on. I even tried it now as suggested in now playing now still no improvement there on my side

[Dreadlau]

from http://www.ventismedia.com/mantis/view.php?id=7478

Tested build 1353 with the same test as in #7478c23641. Scan with focus on:
Now Playing: 2:12
Location/Music/All (AA view): 15:01
Music node (AA view): 6:56
Music node (Details view): 4:15

Performance is now faster than MM3. Nice!
That said, it seems that Location node for some reason has performance issues. All other nodes have a performance penalty as well, but not as severe.

Would it be possible to make the scanning time in Mediamonkey way less dependent on what node is focused.

The problem is not only the location node.
Music node (Details view) takes 4:15. That's almost twice as the now playing node (2:12).

If this is caused by file reading/view refreshing. maybe change how this works.

[PetrCBR]

The slow down on Music node (or many others) is because MM need to check every track whether it belong to selected node and collection. With Now Playing node it doesn't need to check anything so that's the reason why it's that fast.

[robojock]

But even in now playing node mm4 scanning is slow. At the rate it was going it would probably take a week to do a scan of my library

[Dreadlau]

The slow down on Music node (or many others) is because MM need to check every track whether it belong to selected node and collection. With Now Playing node it doesn't need to check anything so that's the reason why it's that fast.

Anyway to make the check more spaced or more efficient? Or maybe even disable it till the scanning is done?

[windcrest77]

The slow down on Music node (or many others) is because MM need to check every track whether it belong to selected node and collection. With Now Playing node it doesn't need to check anything so that's the reason why it's that fast.

Anyway to make the check more spaced or more efficient? Or maybe even disable it till the scanning is done?

I'd make this a new Options user preference for batch jobs with the following choices:

----------------------

Update user interface while running batch jobs as follows:
1) Update UI every record (slowest mode)
2) Update UI only if a record changed (slow mode, avoid unnecessary updates but keep me informed on a per-record level)
3) Update UI every 1% of the total batch job (consistent mode, 100 UI updates no matter what the batch size is)
4) Just let my batch jobs run in the background and dont update the UI at all except when it is finished (fastest mode)

----------------------

MM3 currently uses option #1 (I think based on empirical knowledge). Of course all batch jobs should make sure DB corruption does not occur if the machine or MM is abnormally terminated in the middle of a batch job. IMHO option #3 should be the new "default" if they did not choose anything else "consistent mode".

With the above user preference everyone can be happy and all batch jobs would have a way to tell how the user prefers to work.

[Dreadlau]

I was just worried for the new users.

The kind of users that would set these options are power users.
They already know that they need to change the focused node.

[robojock]

I was just worried for the new users.

The kind of users that would set these options are power users.
They already know that they need to change the focused node.

I didn't know that and i have been using mm for years now

[robojock]

@ the devs

I was doing a scan about 5-6 hours later of frustration i decided to cancel the rip, the report window that pops up telling you how long and how many files it scanned said it was an hour and 44 mins. Which i know for a fact is not true!