Cannot drag and drop to MusicBrainz Picard since v3.32

Starting with 3.32, I can no longer successfully highlight several hundred tracks in mp3tag and drag and drop them into another program like Musicbrainz Picard. I tested newer versions including 3.32 and 3.34 beta today. Downgrading to version 3.31 or lower immediately fixed the issue. Picard changes the cursor as it normally does to indicate that files are ready to be dropped after dragging and moving the cursor to Picard, but no files are dragged after releasing the left mouse button.

This may be a continuation of the issue described here: Drag & Drop bug in mp3tag v3.32 Windows 10 - #14 by Florian

Unfortunately the copy and paste suggestion is not supported by all programs, Picard included, so I am hopeful that I can avoid staying on an older version due to removed functionality.

It's working fine here using latest Mp3tag v3.34-beta.1 and Picard v2.13.3. Can you drag and drop fewer files to Picard, or is it independent of the number of files?

Hmm, I installed Mp3tag v3.34-beta.1 once more just now, and I can confirm large numbers of files cannot be dragged to picard. Dragging several files (1, 2, 10 files) works intermittently.

Reinstalling 3.31a once again immediately fixed the issue; dragging even hundreds of files works consistently.

I've tried it with 500 files and all of them were dropped on first try (and subsequent tries).

Anything special about the files that aren't transferred, like extra long path names?

Yes, some have longer path/file names which work fine with 3.31a but not after that. It either fails to drag any files or it drags all files, never a portion of the selected files. Hopefully support can be reenabled for long file names as with 3.31a and earlier, if that is the issue. 3.31a and earlier works perfectly with all my files of any path length.

Another possibly related issue, even for 3.31a 64 bit, is that files in path+file names over 260 characters cannot be dragged into the program (error file cannot be accessed). I can confirm that dragging the folder containing the file works fine, and dragging the individual files into other programs like foobar2000 work fine. I am trying to bulk rename various files, some of which are longer than 260 characters. Hopefully this bug can be fixed in future versions.

I've just tried with a file path > 260 characters and drag and drop into Mp3tag v3.34-beta.1 worked without problems. Also, dragging this file to foobar2000 and MusicBrainz Picard worked.

Is there something more specific that's triggering the issues you're describing. Please also include the names of the source and target applications in your description, just to be sure that I'm trying to reproduce using the correct sequence.

Did you try with a very long file name in a long path? Those are also troublesome in the latest update. I’m using the latest foobar 2.26 x86 preview and the latest picard. I am also on Windows 10. Since it works with the older version and doesn’t with the newer version, and repeated testing of installation/uninstallation proves the issue is repeatable, it appears to be a change after 3.31a that makes this operation no longer possible.

Yes, with this (> 500 characters)

c:\Users\florian\TestFiles\MP3\012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\001 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 012345.mp3

It works both in foobar2000 and Picard, the former displaying the file path in the 8.3 notation C:\Users\florian\TESTFI~1\MP3\012345~1\001012~1.MP3, the latter in the long filename notation as \\?\C:\...

I basically had to re-implement everything drag and drop related due to repeated crashes with the framework-provided solution I used before. Here is the protocol of this daunting process for reference:

Unfortunately, due to the inherent issues with this solution, there is no going back.

I think at this point I need more details on how long the file names and paths are for the files that are failing for you.

Also, what's the minimum number of files that let you reproduce the issue?

It looks like this is going nowhere at the moment. I've also setup a new Windows 10 installation in the meantime but also couldn't reproduce the issue when starting from a fresh install.

Is anyone else also affected by this and can provide details on how to reproduce the issue?

Moved to Support and set to close in two weeks.