View Issue Details

IDProjectCategoryView StatusLast Update
0018490MediaMonkey 5Tagging / organizing (properties / auto-tools)public2022-04-11 17:58
Reporterpeke Assigned To 
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionunable to reproduce 
Target Version5.0.3 
Summary0018490: Properties: Multi Edit to change type takes full tagging even no tags are changed
DescriptionSelect 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.
TagsNo tags attached.
Fixed in build

Activities

michal

2021-11-01 17:48

developer   ~0065618

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?

peke

2021-11-03 01:12

developer   ~0065660

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.

michal

2021-11-03 08:35

developer   ~0065669

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.

peke

2021-11-04 02:29

developer   ~0065705

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.

michal

2021-11-04 07:10

developer   ~0065708

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.

michal

2021-11-08 12:01

developer   ~0065797

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.