View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019044 | MMW 5 | Main Panel | public | 2022-05-02 14:24 | 2022-05-04 20:51 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.3 | Fixed in Version | 5.0.3 | ||
| Summary | 0019044: List (by Album) view is slow to load for large folders with recursive content on | ||||
| Description | Go to Folders > Network > \\NAS > music > all i.e. enable 'Display folder's content recursively' While loading 11000 files takes just several seconds in 'List' view, doing the same in 'List (by Album)' view takes endlessly. Workaround is to load the list in 'List' view and once all tracks are loaded switch to "List (by Album)" view. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2620 | ||||
|
|
This sounds like a good idea, but I have some comments: Ludek: "loading 11000 files takes just several seconds in 'List' view" I tried this with version 2617, 49081 files now takes 4:40 minutes ... in List View Significantly better than before, and with none of the irritating flashing and jerking. But seems much slower than you are reporting. 49081 files, 1135 gb, 901 folders. I do have more folders than you, or is due to fact I have large flac files, or ....? I cross checked it with the time that File Explorer takes to count the number of file and sum the disk size. It took approximately the same time. I do note that it reports more file & folders, ie +7,000 files above what MM reports, and + 4,000 folders. I presume that is the logs from my file rips, and the external art files, and all the lower level album folders that you are not reporting in the MM status bar Maybe Ludek has less non-media files, and less album level folders, which helps explains why everything seems, for him, 5+ times as fast as I am seeing? The standout observation for me is that Windows Explorer and MM5 can open can open and display the contents of my Music share instantaneously ... This is because it has only 900 top level (artist) folders. If I am using the Recursive button, this instantaneous response is now 4:40 minutes!, because the Recursive button is not as targeted as the "All" button was in MM4, where I could target the scope of what I have asked to be opened. I have to learn to remember to turn it on only when I have low enough down into the hierarchy. I acknowledge this is less significant issue where one is navigating via the bread crump menu. For me, it is a poor design that the button is sticky. ie. in 2617: 1) navigate to Folders node, navigate into an artist, and then press Recursive 2) finish what i am doing there 3) do something else in the same tab, ie. navigate to Home>EntireLibrary 4) Later, go back to Folders node 5) Recursive is still on 6) wait 4:20, unless you know to untoggle the Recursive button While checking this MM5 froze (48C4DFBA, blocked thread) I cancelled off all MM tasks, and rebooted MM5 ===> Recursive defaulted to on ! I still think that this all sux. |
|
|
Fixed in 2620 |
|
|
Re the Barry's note: Yes, the difference probably is as explained by Barry (depending on count of folders, files, subfolders, accompanying files, network traffic etc. etc. Therefore it is always faster to browse folders of files already in library via the Location node. Re the design issue, this is being tracked in separated issues like 0018494 and 0018909 |
|
|
It seems that switching View while the list is loading starts loading from 0. Although faster than the initial loading it's much slower than switching Views after the list has been loaded. On 2620 loading of List and List (by Album) seem to be on par in time taken. |
|
|
>> It seems that switching View while the list is loading starts loading from 0. Although faster than the initial loading it's much slower than switching Views after the list has been loaded. << Yes, on switching views only the fully loaded lists are cached for later usage -- otherwise the loading is canceled (as it is not predicable whether the list will be needed by the other view (like switching from 'List' to 'List (by Album)'). Could be tuned up further sometimes, feel free to enter it as another issue with 5.1 taget, but changing it now would be too complex with high risk of a regressions for such a minor issue. >> On 2620 loading of List and List (by Album) seem to be on par in time taken. << Thanks, this confirms the fix of the issue in question here. |
