MediaMonkey forum

In MM4 I got a sub second from this:

• open MyComputer node

• navigate to the music share on my NAS

• type a search string ==> sub second navigation response

• if I accidentally typed a search string which was not matched, MM4 positioned to closest matching position type HHH ==> MM4 positioned to "Haden"

The equivalent in MM5 is not good ... not sub second ... takes about 23 minutes!!:

• open Folders node

• click on the music share in my NAS

• type hhh

• MM5 finds no match so seems to start reading every track in my music share .. examining the track's metadata? ==> not a good idea in a large library ... is taking approx 30 seconds for each 1,000 tracks ... so that means that it going to hammer my NAS for approx 23 minutes before it responds to say that hhh is not found.

Just tried, but I cannot replicate. From your description it seems that you used "Scroll to match" type of contextual search,
I tried the same with my NAS and gone to NAS > Music with "Display folders content recursivelly" so that it is loading all tracks to a single tracklist.

I see the tracks slowly loading (once it reads more and more tracks with its tags) and when I type "hhhh" it immediatelly show "hhhh" phrase not found:
https://www.dropbox.com/s/99mopd03ixper ... 2.png?dl=0

If I type just "h" then the correct track is immediatelly scrolled into view (even when the other tracks continues to load)

So I am not sure what I am doing differently than you, could you catch this in a video with debug log generated (DbgView started prior MM5 start) ?
Or are you just saying that tag reading from your NAS was faster in MM4 > My Computer node ??

Thinking about it again and in addition to what I write above:

Barry4679 wrote: ↑Mon Dec 21, 2020 3:35 am

• MM5 finds no match so seems to start reading every track in my music share .. examining the track's metadata? ==> not a good idea in a large library ... is taking approx 30 seconds for each 1,000 tracks ... so that means that it going to hammer my NAS for approx 23 minutes before it responds to say that hhh is not found.

But maybe it is just the "Disaply folders content recursivelly" option: https://www.dropbox.com/s/g2yo3an2y4gk7 ... 3.png?dl=0
that confuses you? Because in that case it works like "All" node in MM4 and reads all the tracks (including subfolders) from the share.

EDIT: It could be laso related to https://www.ventismedia.com/mantis/view.php?id=17273 that I have just fixed for 2289.
Where MM5 needlessly read also embedded artwork from every Flac file under Folders node

Ludek wrote: ↑Mon Dec 21, 2020 9:22 am Thinking about it again and in addition to what I write above:

Barry4679 wrote: ↑Mon Dec 21, 2020 3:35 am

• MM5 finds no match so seems to start reading every track in my music share .. examining the track's metadata? ==> not a good idea in a large library ... is taking approx 30 seconds for each 1,000 tracks ... so that means that it going to hammer my NAS for approx 23 minutes before it responds to say that hhh is not found.

But maybe it is just the "Disaply folders content recursivelly" option: https://www.dropbox.com/s/g2yo3an2y4gk7 ... 3.png?dl=0
that confuses you? Because in that case it works like "All" node in MM4 and reads all the tracks (including subfolders) from the share.

EDIT: It could be laso related to https://www.ventismedia.com/mantis/view.php?id=17273 that I have just fixed for 2289.
Where MM5 needlessly read also embedded artwork from every Flac file under Folders node

Probably it was caused by the "Display content recursively" control.

I think that the Folders node is probably the least successful change in the GUI ... I have what is probably a simple suggestion to improve.

Problem: in the Folders node the Grid (folders) control is active by default. ... When recursive is set on it has a top section containing Folder icons, and also a bottom section containing a file list.

In a large library the top section is very large, so the user does not see the bottom section unless they do a lot of scrolling down.
It is not obvious that every lower level node is being opened, because on the top level nodes fills the display.

Opening all the bottom level nodes takes a long time ... even after your bug fix I am still seeing that it takes 55 seconds for each 1,000 tracks ... I don't have much art embedded in the tracks, so I did not see a great improvement.

Looking at the time taken it becomes obvious why Windows Explorer was implemented as a tree control, and that there is no "Open all nodes" menu in its context menu. ... ie 50,000 tracks ==> a 45 minute response time.

MM5's Recursive option is an "open all nodes" option. .... and is a sticky control ... ie. when the node is opened the option remains set as the user last left it

Solution: the Recursive option should not be sticky ... it should be reset to off whenever the user navigates to the node ... and also reset to off whenever the user navigates to a different node within the Folders node.

So it becomes a toggle ... something like the track's File Properties dbox ... if I have that open in a view, then close MM5 and restart it ... the File Properties dbox is not sticky .. ie. is not reopened.

I think that this simple change would reduce the incidence of issues where the user does nor realise that Recursive is on ... and finds that MM5 is very laggy while it takes 45 minutes to thrash the hard drive

Opening all the bottom level nodes takes a long time ... even after your bug fix I am still seeing that it takes 55 seconds for each 1,000 tracks ... I don't have much art embedded in the tracks, so I did not see a great improvement.

Based on your log re the issue white screen here: viewtopic.php?p=475947#p475947
you had 2.8 GB occupied by artwork and MM5 gone "out of memory", so yes, this was instance of https://www.ventismedia.com/mantis/view.php?id=17273 fixed in 2289

Solution: the Recursive option should not be sticky ... it should be reset to off whenever the user navigates to the node ... and also reset to off whenever the user navigates to a different node within the Folders node.

Hmm, sounds as easy and good short term solution. Added as https://www.ventismedia.com/mantis/view.php?id=17281

Thanks!