View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0020991 | MMW 5 | General | public | 2024-06-05 17:31 | 2024-07-24 18:18 |
| Reporter | zvezdan | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.1 | ||||
| Target Version | 5.1 | Fixed in Version | 5.1 | ||
| Summary | 0020991: MM5 is too slow with files from Folders | ||||
| Description | MM5 is way too slower than MM4 with files from the Folders branch, even when switching skin. I tried the next test with 181 files in 16 sub-folders, MM5 with enabled option to show all sub-folders, MM4 with selected All node. MM5 List view (similar result with Grid by Album) about 13 seconds to switch skin, and another 32 to fill the list. 24 seconds to refresh (F5). MM4 Show details (similar result with Show Art): about 10 seconds to switch skin, 0 to fill the list. under a second to refresh (F5). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 3030 | ||||
|
|
Good catch, FYI important step to replicate is not having the songs in the library/database.. |
|
|
Fixed in 3029 |
|
|
It is not much better in 3029. The same folder is scanned after skin switching for about 28 seconds (and another 13 sec for skin to change). Now with missing artwork. |
|
|
Based on your last log the files reading from D:\ is somehow slow, what's that drive, is it HDD or SSD? e.g. file:///controls/playerSwitch.js, took: 281 which is extremely long time for just one JS file i.e. the JS files are read from D:\ while file tags are read from C:\ at the same time and it somehow makes the whole reading slower. And for some files the tag reading takes almost one second, e.g. file: C:\Music\Rock\Pink Floyd\Pulse\213 - Run Like Hell.mp3 I wonder whether it is always so slow for this particular file? Could you lpease generate one more log, but wait e.g. 10 seconds after the skin switch (until all JS files are read/loaded) and then switch to the folder so that I could compare the tag reading times between the two logs? EDIT: And also one more test: Is it also so slow when DbgView is closed? As I see quite massive DbgView ouput which could slow it down. |
|
|
OK, I think that the massive DbgView output has influence, based on my tests: Folder including 786 files in total is read in 2 seconds when DbgView is closed while it takes more than 4 seconds while DbgView is opened.. So reducing the debug output could help here.. The same times with MM4.. |
|
|
Why did you delete your post? Do you want another log or not? By the way, I answered to you about my computer in 0020639 issue, it has M2. drive PCIe Gen3x4 NVMe SS TLC MM4 doesn't have any issues with the same drive, same folder, same files and same tags. |
|
|
I did not delete my post, I actually made another, but made them both private, do you see my private notes? For me folder including 786 files in total is read in 2 seconds when DbgView is closed while it takes more than 4 seconds while DbgView is opened.. The exacltly same times with MM4, could you please add also MM4 log for the same folder to compare? |
|
|
What the heck is that with private posts? I don't see your private notes here, in Mantis, but I got one in e-mail (as all other that are posted to my reports). Did you see my private notes in Mantis, e.g. in the 0020639 issue? |
|
|
Yes, I can see your private notes, I'll ask Rusty/Jiri why you don't see mine.. EDIT: Made my private notes 'public' temporarily so that you can read them.. I reduced debug output to make it faster when DbgView is running for build 3030.. Could you please do the following logs for me: 1) Run DbgView, run MM5 and wait until nothing new is added to DbgView, then access the mentioned folder and let it read all the files, save the log 2) Run DbgView, run MM4 and wait until nothing new is added to DbgView, then access the mentioned folder and let it read all the files, save the log Thanks! |
|
|
BTW: So that we don't need to communicate via Mantis notes I can give you my SKype name or feel free to use my email (I'll add you to my whitelist).. |
|
|
I am sorry, I did previous test with release version of MM4. I don't know how I got it at first place, I always downloaded debug versions. MM4 debug requires about 22 seconds for the same folder (16 albums, 180 files), so it is not much faster than MM5. DebugView is horrible. That is 1 second for release versus 22 seconds for debug. MM5 is displaying the same folder under a second when DebugView has logging stopped. You can close the issue. |
|
|
It is really strange that DbgView has so significant difference for you, anyhow I reduced the massive DbgView output for the next build, so it should act faster even with DbgView running... Just to ensure: Your drive D: on which portable version of MM is installed is also SSD drive or a network/usb storage? This would explain the slow MM5 start.. |
|
|
As for the slow start: I guess this does not depend on DbgView running or not? From the DbgView logs I see that MediaMonkey.exe is launched in a second, but then it takes another 8 seconds before first messages from MediaMonkeyEngine.exe are logged, it looks something is blocking loading MediaMonkeyEngine.exe from the M2 into memory.. This usualy can do some anti-virus SW, but supposing you are using just Windows Defender then it should not be the issue.. What's non-debug build start time? Is it significatnly better or no? Tracking this issue as 0021013 -- so let's continue there.. I added some other findings there to 0021013 |
|
|
Closing re verified 3039. Not an issue anymore as startup times are handled withing 0021013 |
