View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018490 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2021-11-01 13:50 | 2022-04-11 17:58 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Target Version | 5.0.3 | ||||
| Summary | 0018490: Properties: Multi Edit to change type takes full tagging even no tags are changed | ||||
| Description | Select 500 Video tracks -> Right click -> Properties -> Change Video to Music Video -> OK it takes several minutes to update. Expected to be done within a second as it is only MM library change and how MM5 handle those tracks. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I cannot reproduce, for me it really changes only DB, media files remained untouched. Could you retest and confirm, it really tagged something for you? |
|
|
I can confirm taht I still observe descibed behavior. Log and accompany Video sent offline for analyze to see why. I noticed that slow DB update happens only first time Type is changed. |
|
|
But log shows, that files were not tagged, only DB updates with GUI updates were made. I've made some testing and it is result of many DB updates on large DB (3 tables need to be updated for each track) together with many related debug messages and list updates in GUI. Try to close DbgView and it will be a lot faster, for me this is the main reason for slowness. |
|
|
DBGView do not influence Slowness. I always test without DBGview started and then Replicate with logging. I sent you video with Higher res. Main thing is that after I leave that update finishes all all those 80 Tracks and sub sequential changes finishes within a few seconds. If you still can't find reason I can do another recording of LOG and video as needed. |
|
|
Well, DBGView influences speed a lot - for me, changing type for 2500 tracks lasted 31s with DBGView and 6s without DBGView (always tested as first thing after app start), it is huge difference. |
|
|
I have tried your DB and the reason is your "Jingles" collection, after hiding this collection it is a lot quicker. In this collection you use non-indexed column "length" as main condition, updating this collection after editing in your large DB is what is causing the delays. |
