Sidebar tag editor

[redwing]

This time exe file was quarantined with MusicBeeLibrary.mbl and .bak file as well.
But I couldn't reproduce the bug with track info panel in selected track mode, though lagging was more obvious with more clicks.

[Steven]

Just selecting files would not cause MB to touch in any way MusicBeeLibrary.mbl and .bak and clearly their heuristic filter is flawed and from their response they have no inclination to address when its flagging false positives.

If we are going to go through the same shit now with Bitdefender as with Avast then i am going to seriously reconsider how I support and distribute MusicBee.

[redwing]

I'm just clicking on files, but I see the library file gets updated occasionally. Why is that?

[edit]
Never mind. That's because Bitdefender forces quit MB during a session and it gets updated on exit. Quarantined again the same files. This time I clicked on files real slowly.

[Steven]

did you get the windows 10 fall update recently?

[redwing]

I got it in October.

Here's an update. I changed the path for MB and it no longer gets quarantined.
Also I found the lingering highlight bug is reproducible even with the latest 3.1 as well as the one you just released. But it no longer triggers Bitdefender's reaction. I think it has a flaw in clearing out once quarantined app completely from its memory. You have to change the path not to be affected by its history.

[Steven]

this version should not lag any more when selecting files.
Also it now has hotkey support to show/ hide the vertical tag editor

http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip

[redwing]

I ended up uninstalling Bitdefender as it again started to quarantine MB.
Feel free to split my posts regarding the AV to a different thread as it's not really about this topic.

[redwing]

I think I found what causes the issue: it's Track Information panel in selected track mode.
When it's playing track mode, the bug never occurs.

I found why this happens (at least to me). It's artwork on track info panel. If I hide the artwork, I can't reproduce the bug. It's not directly related to tag editor since I can occasionally reproduce it without tag editor open, but when it's open reproducing the bug is easier.

[redwing]

This might indicate some issue with artwork on track info panel. Show one album in the main panel and link for the artwork to a big image file (5-10 MB). Selecting each file on the main panel is easy if you hide artwork on track info panel. But if it's shown it takes quite a time to select each file. Now open tag editor. It's now much harder. Hide tag editor and sidebar, then it's quick again (I think this might be the reason for the high CPU usage for file importing since some of the files in my collection get linked to a big image).

But the highlighting bug is not always about the image size. It looks random, sometimes occurring with 300x300 image.

[Steven]

i will agree with you that showing a huge picture when selected tracks is displayed in the track info panel will slow down the rest of the GUI. I guess i could do something about that. I do see any difference whether the vertical tag editor is open or not, nor can i see any reason how it could affect the slowdown (it would affect the other tag editors).
However in no case have i ever been able to reproduce the issue you are reporting. I might look at the track info panel to address the slowdown for the rest of the GUI but not willing to spend more time trying to determine the highlighting bug

[redwing]

I should have been clearer, but I meant tag editor docked at the bottom, not the vertical tag editor, just in my previous post.

[redwing]

The highlighting bug is a very recent one. I've never seen it before this month. If it's not directly related to the implementation of the vertical tag editor, what would be other recent changes that might possibly be responsible for the bug? And it has to be related to artwork handling on track info panel. My guess is the following two changes:

The side panel reflects the last explicitly clicked track. When you switch tabs the active selected track can change eg. you previously had a file selected in that tab.
The one exception to that rule is the tag editor docked in the main panel, which will change to the current selected track.

Having said that i do see a bug where you click the current selected track in the new tab, and the sidebar panel doesnt update.

To make things more consistent i guess switching tabs should also change the active selected track in the right sidebar

and

i have made a change for the next update based on what i think plausibly may be happening - it would be down to chance so i would need to be working ok for a while to be sure. I also think i know why it wasnt resetting on the next restart. You will still need to manually resave the existing ones with this problem.

Both were right before you implemented tag editor. So maybe it introduced some potential issue, and the tag editor made it active. I hope you review those recent changes you made to see if there's something related to the issue.

One more thing. I don't think whether you can reproduce the bug is such a big deal. It would surely help, but I've seen numerous times you weren't able to reproduce the reported bug for some reason but you managed to fix all those bugs. Maybe this is one of those cases where some users can reproduce more easily than others. I can tell you whether your fix makes any differences regarding this issue even if you can't reproduce it.

[Steven]

i have made a change so that switching tabs now causes any panels set to "Selected Tracks" now update to the selected item in the main panel.
http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip

[redwing]

Regarding this wish:

- Disc# and Track# could be shown on the same row if the width allows

it could be expanded to other fields as well like year and original year.



Also there are other short fields (rating) and some fields that could be shorter (BPM). So if the user adds such short fields consecutively, it could put two fields per row as long as the width of the panel allows.

The reason for this request is that the user can only add as many fields as the limited vertical space allows. So each row counts, either for the number of fields that could be added to the tag editor or for the height of other elements placed in the same panel.

[redwing]

If a field has mixed values when you select multiple files, vertical tag editor cannot clear the field. Tried with genre, grouping, comments tag. It clears it only when the field has the same value for all selected files.