View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015579 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2019-04-02 21:58 | 2020-07-15 02:21 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015579: Update Tags on edit can make MM5 much Slower | ||||
| Description | Tagging network files immediately after editing properties slowdown MM5 and in case of connection issues can result in crash. There is a space to improve this: 1. Add sub option [x] Local Tracks only so that Network files are not updated immediately 2. Add delayed update in order to make more priority to UI 3. Add Edited Flag to Library itself so that MM5 can more easily know which files are not synced 4. Ability to close MM5 without prompt "Background tasks are running do you want to quit" and on startup MM5 will continue updating files My tests also confirms users behavior MM5 is much faster if update on Edit is disabled. | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?p=457357#p457357 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2169 | ||||
|
|
Do you have some other logs with except for the user logs that I have already fixed for 2168 ? |
|
|
I have not created new logs on my PC but I opened bug as I can confirm slower behavior if update tags is enabled so that we can evaluate what can be improved in future versions. Please triage as you see fit. |
|
|
Tagging is done on a background thread -- so it shouldn't affect UI thread (unless there is a bug). It can be slower with the HDD/network access, but I think that with the choice: [x] Update tags when editing properties it should really update tags when editing properties. So I suppose that "no change required" |
|
|
EDIT: I can also confirm a slow UI behaviour when editing a large number of tracks at once. This is observable in [Music > All tracks] node -- probably caused by the queued UI updates for the tag changes (or something like that). To be looked into and optimized. => improved in 2168 and fixed various issues and tweaks related to mass edit |
|
|
I'm not 100% certain that this is the cause, but tagging operations in build 2168 seem to be taking very long and using close to 50% CPU utilization. I've experience this whenever a podcast update occurs or whenever auto-tagging tracks and navigating the Locations folders while the operation is underway. Note: I'm setting this as 'immediate' because it seems to be a major regression (and I've held off on posting 2168 because of this). |
|
|
I don't see this, please generate: - log from 2167 and tagging the same group of tracks - log from 2168 and tagging the same group of tracks So that I can compare the logs and see whats wrong on your end EDIT: Also screencast videos demonstrating the issues (2167 versus 2168) would be valuable (so that I can see what actions your are doing and what the issue is) |
|
|
I'll generate logs as requested, but in the meantime, here's a bit more info. After I attempted to auto-tag ~10 tracks, MM was 'stuck' doing this overnight. When I attempted to close MM in the morning, it generated Debug log 46CB38DA and then displayed: Not all close query events are finished !! took: 10281 | callstack: Callstack: Script: file:///maincontent.js ; Func: undefinde ; Row: 54 ; Col: 27 Would you like to restart MediaMnokey in Safe mode? |
|
|
Based on the 46CB38DA it has frozen on DB access layer (SQLiteDB.TransExecLock). e.g. also the tagging thread was waiting for the DB access (in UpdateSizeAndDate) EDIT: I think that I have found the cause of 46CB38DA, was a long standing issue (could happen also in MM4) => fixed in 2169 and also in the MM4 branch |
|
|
OK. Tagging as resolved. I'll retest in 2169. Note: I haven't been able to replicate the problem since I rebooted my PC (I'm wondering if maybe it's related to memory constraints?). |
|
|
Verified 2170 I am not being able to replicate. |
|
|
Holding off on verifying until 0015592 is fixed. |
|
|
Verified 2260 Unable to replicate any slowdowns after stress testing it for 2h with background jobs and open/close. Noted that in some cases MM5 closes slower, but it takes no longer than few seconds. |
