View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018909 | MMW 5 | Main Panel | public | 2022-03-05 09:03 | 2022-05-02 15:07 |
| Reporter | barrym | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Fixed in Version | 5.0.3 | ||||
| Summary | 0018909: Recursive button on Toolbar is global (?) | ||||
| Description | Controls on the left and middle of the MM5 Toolbar are specific to the current tab. Except for the Recursive button, which is global. This unexpected, and is also very annoying. The design decision to switch from the MM4 ALL node leaf, to the Recursive button, is decremental with large collections of tracks which are stored on a Network drive. Even on a cat 6 wired Ethernet connection, with Recursive set on, there is a big lag while MM5 discovers all the nested folders and tracks ... in most cases this is a pointless lag, because I have no intention of going everywhere. During this lag, the UI is unstable, and Power Scroll of the tree is temporarily broken, as described in the attached forum thread. The work around is to leave Recursive turned off. But in a two tab MM5 operation like cut and paste albums from a local drive to the network drive, I want one of the tabs to have recursive turned on. This was not a problem in MM4 because I had control over how deep MM5 would try discovery. The MM5 design would be OK in this Use Case if the Recursive button was tab specific. | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?t=101489 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2613 | ||||
| related to | 0018257 | resolved | Ludek | Filters persist when changing nodes |
| has duplicate | 0017281 | closed | Ludek | Display folders recursivelly shouldn't be sticky option |
| related to | 0018922 | closed | Ludek | Context Menu: Send To have long loading in case recursive show is enabled on Folders |
| related to | 0019044 | closed | Ludek | List (by Album) view is slow to load for large folders with recursive content on |
| related to | 0018494 | feedback | rusty | Return the ALL leaf to Folder and Location nodes |
|
|
Further feedback from Barry here: https://www.mediamonkey.com/forum/viewtopic.php?t=101489 Assigned to Rusty for triage... |
|
|
I tend to agree with Barry that the state shouldn't be sticky, in MM4 it also was not a global sticky option and user had to always click 'All' subnode to list files from all subfolders. This would resolve also related sub-issue 0018922 |
|
|
Fixed in 2611. i.e. "Display folder content recursively" button state is no loger sticky/global. Let's collect feedback on this change... |
|
|
After reviewing practicality of the new non-sticky behaviour of the Recursive button, I think that the current change is too severe, and will probably be unpopular. Test: * List by Album View * navigate to an artist folder ... turn Recursive on * navigate to a different Artist folder ... recursive is auto turned off ==> unlikely to be expected nor desired, and since any artist folder will be relatively small, it delivers no benefit either Could the auto-turn off be enacted in the following circumstances only: 1. Navigation which **changes to** the Folders or Location nodes ... ie. navigation from somewhere else, which effectively is the start of navigation "session" within a specific Location|Folder node 2. Navigation, during a Location|Folder "session" which changes to a different disk root ... ie. to a different disk drive, or to a different network share I think that this will be less disruptive, and easier to understand, and sill deliver the benefits that were the aim of the change. |
|
|
Assigned for review |
|
|
Some negative feedback re this change in [Ticket # 3953] Left assigned to Rusty for a review whether we should just revert this change or tweak it further. |
|
|
Assigned back to me, IMO the last Barry's suggestion (note 0018909:0067349 ) how to make this less desctructive makes sense. Fixed in 2612. i.e. the state of the "Display folders content recursively" remains active in the browsing session of nodes that supports this feature (until user browses to a node that doesn't support "Display folders content recursively" or MM5 is restarted). |
|
|
I don't like the changes that have been made regarding this. If I turn Recursive on I expect that to stick as a setting, not get automatically disabled. Navigating between Recursive capable nodes to non-capable and back is common and now you keep having to turn on recursive. The problem to address here was multi-tab behavior. It'd be nice to have Recursive (but also View, etc.) be able to be different between tabs. This would mean that MediaMonkey would have to remember a per tab settings values for these things. |
|
|
OK, made it tab specific in 2613 |
|
|
I didn't get to experience the last hack at this request unfortunately because 2612 not available to me yet. I agree that the original request was to stop being global, which the Lowlander suggestion meets. He prefers that Recursive be sticky, presumably because he always has it on. I have all of my tracks on a network drive. I prefer recursive to be off by default, due to all the disruptive flashing and jerking about effects, and focus stealing, that happens while a large drive is traversed, which can takes many minutes. In MM4 Recursive was always defaulted to off, ie. you needed to click all node, or open a tree sub-node, to trigger traversal. This new situation is an improvement; ie. I can have * tab #1, with recursive ON, open in Location node pointing to my rip location on a local drive * and tab #2, with recursive OFF, pointing to my large network drive ... I use this as a drop zone, it never has to be opened recursively But as I understand it Lowlanders suggestion is that there be a separate Recursive setting for each tab, And the the setting is to be sticky. So if I set it on in a tab, for some purpose, then leave the Folder|Location node, it silently remains on. And if I got to Folders or Locations node again in the tab, it will be defaulted to on? ... I don't think that is good. This default on setting persists after restarting MM5? It persists when a tab is closed and is then reopened? Maybe you have not seen the implication for this for network drives and large collections .. ? * I have a moderate collection of 48k of flac files ==> 1,132 tb * NAS is connected to my PC via Ethernet (Cat 6) * I think that the data transfer rate is over just 100mb per second * PC has 4 cores and 24gb physical memory * if MM5 opens this collection, with Recursive on, it is going to take over ONE HOUR while it stuffs around checking the tracks, and refinding the art in the MM5 cache * for this hour MM5 is using **25%** of the CPU * the MM5 UI is usable to some extent ... there is some impairment ... and the screen flashes and jerks about every few minutes * FOR AN HOUR! * and you want to leave Recursive in a defaulting to ON state ?? * OK, so it is easy enough to flip the Recursive switch off when this happens ... if the user realises that this is the cause of the problem * otherwise what can they do ?? ... Probably uninstall. * video showing the 1st few minutes of the hour :https://www.dropbox.com/sh/35y8ovau4u789uo/AADmSL2apjjX35Bmqfr74LxZa?dl=0 * another video showing the 15 minute mark, this one also showing resource utilisation: https://www.dropbox.com/s/zpabquydz9gntq5/15%20minute%20mark%2C%20inclusing%20utilisation.mp4?dl=0 |
|
|
I verified your 0018909:0067440 implementation in 2619, I am not being able to replicate Barry 1h CPU overload (my CPU stays at 5-7% on 8+ threads), but that it is slow it is slow even on m.2 NVMe drive with 10k sample. Maybe we should consider loading in batches or limiting to 1-2 levels by default? Or like Barry pointed Disable recursive 0018909:0067460 for network drive as it is very likely that we have users that have both NAS and PC over WiFi where reading 10k would be real pain even in WiFi 6 (ax) with full bandwidth and signal. I suggest either opening new bug or push for performance testing in 5.0.4 |
|
|
I can repliacte the slow loading that Barry is experiencing, it is related to "List (by Album)" view, workaround is to load the list in 'List' view and once all tracks are loaded switch to "List (by Album)" view. => to be fixed as 0019044 |
