Unreliable selecting actions

[terryo]

MMW 2024.2.0.3150 troubles. Fast PC all music on 4TB nVME drive.

I'm retired from 35 years of doing a live radio show and trying to clean up my library from years of scrambling chaos from the deluge of new releases and trying to keep a library up to date. Most of what I am doing now is changing blocks of fields, predominately genre, but also dates, publisher...

I ran DebugView this morning to capture the unreliable song selections that arise when multiple field changes stack up. I was able to stack up enough to make the behavior recur. I've forgotten how to submit a debug file. It may be difficult to parse as the program continued to process the field changes after the selections went weird.

Basically, I'll click the mouse on a song, then hold ctrl and try to select a block. MM then highlights a completely unrelated block of songs. Or it selects every song from the top down to the second (ctrl+) click regardless of where I first clicked. Sometimes MM just locks up and eventually Windows figures out it is not responding and it crashes.

The maddening part for me is, when MM locks up, the display shows the changes I made, but the action line at the bottom still shows hundreds, if not thousands of database changes that have yet to be done. After I do a restart, how can I be sure the database matches what I see on the display? I have close to 300,000 titles in my library and if the MM database is becoming unreliable, a mismatch will be a major loss of my labor.

[terryo]

My message contains a brain fart error. I'm selecting block of titles using shift+, not ctrl+

[terryo]

I'm running another round and the MM screen froze. Debug is still logging activity. I'm going to let it run until debug stops. Usually the program freezes at that point. This time it did not freeze.

Tracking this stuff down is a pain in the ass. But you probably know that.

[terryo]

Now my faith in MM is seriously shaken. While updating my library, I failed to notice, until it was too late, that MM 2024.2.0.3150 doubles the entries on display while it is processing its database. I deleted some of these duplicates until I thought, 'hey what's going on?'

So I checked the Path column and found the locations of the duplicate and regular entries were identical. I deleted albums from my drive until I discovered this bit of up programming. Some of entries for this music IS NOW PERMANENTLY LOST! and I have root around in the Recycle Bin to recover the audio files.

I have a full debug running while I was working. Please figure this out and tell me when it is FIXED!!!!

Your display should NEVER show duplicates that don't exist.

[rusty]

Hi Terry,

Sorry to hear about the issues with the latest beta

...unreliable song selections that arise when multiple field changes stack up. I was able to stack up enough to make the behavior recur.

Can you clarify what you mean? Are you saying that you just do multiple successive SHIFT-click mass selections and eventually it starts selecting the wrong tracks? What view does this occur in?

And regarding tracks appearing in duplicate: is this related to the SHIFT-click issue? i.e. does it occur after mass selecting groups of tracks successively? Was performing an operation on the tracks necessary to trigger this? What view did it occur in?

Thanks!

-Rusty

[terryo]

I select a block, change an entry, genre for example. Then I select a different block to change another parameter. These blocks never overlap.

The unreliable selection activity, where clicking the mouse in one place results in a selection unrelated to the position of the mouse when I do the CTRL+ second click, does not occur with any predictability. It is likely to occur when background processing stacks up on 3 or more blocks of changes. The interface slows down even though debug shows activity progressing at the usual rate.

Despite what debug says is happening, the bottom activity line eventually stops updating. If I keep working and do multiple clicks and checks to make sure the intended selection is actually made, eventually, the interface ignores all mouse and keyboard activity and freezes completely, sometimes to the point that Windows posts a 'program unresponsive' dialogue box.

My library has close to 300,000 songs. While editing the library, individual selected groups of songs being processed can be in the hundreds, and a few times in the thousands. I realize I am probably stress testing MM5 well beyond the needs of most users. But I seriously thought MM5 was being built for heavy users like me.

[tmf]

I'm having similar (or same) selection problems when editing multiple items, then trying to select another batch while the previous edit is still being processed. It's almost impossible to select more files until MM has finished processing previous edit.

Also sometimes the edits are processed very fast and other times they are extremely slow. Edits are on database text for tags only, no artwork is being added or edited.

MMW 2024.2.0.3153, Win 11 pro.

[Ludek]

Hi,
could you please create a screencast video demonstrating the issue?
e.g. using https://screenrec.com/ , it will produce link like https://screenrec.com/share/L24mIeAGnJ

[terryo]

I won't have time to do the required volume of editing in MM5 that causes this behavior for some weeks.

I also don't understand how a screenshot will help. The display looks completely normal, just selected songs are different then the ones in the locations where I clicked and shift+ clicked.

[Lowlander]

The request is a screencast, which is a video of what you're doing. not a screenshot which is just a static image.

[terryo]

Thank you for the clarification.

Can I start a screencast at any time or do I need to do it well before the issue become apparent. I was told debug needs to be started well before trouble occurs.

It takes quite a bit of stacked editing before I can see when MM5 starts getting wonky on selections. Then it takes even more editing to see it start doubling up track entries in the display. (My bug report ticket combines unreliable selection and doubled entries because they both occur under the same usage conditions).

[Lowlander]

Screencast can just capture the part where it starts (and anything before that may seem relevant). It's the sequence of steps selecting files you take to get the problem to appear that are needed.

[MattTown]

I have also seen some anomalous selection action in 3153, where selecting one track and then shift selecting another above it does not select the tracks in between, but rather selects tracks in the other direction from the initial selection.
Cheers
Matt