Send to new playlist + remove from playlist [#10677]

[joeri_theelen]

I'm using MM 4.0.7.1511 on Windows 7 Professional SP1.

I just encountered what I believe is a bug.

1. select a couple of songs in an existing playlist, not an autoplaylist
2. send them to another playlist using the context menu: send to... > playlist > new playlist
3. give the new playlist a name: the selected songs should now be in the current playlist and the new one
4. while the songs remain selected in your initial playlist, press delete or remove and choose "remove from the playlist only"

The result is that the songs are removed from the newly created playlist, not the original one. You expect the songs to be removed from the playlist you initially selected them in, but this is not the case.

The combination "send to new playlist" followed by an immediate removal from the current one comes in handy if one wants to redistribute or refine the content of playlists. It is a pity it is not working. By the way, it does work if you reselect the songs you've just sent to another playlist, in the initial one, but that is double work and unnecessarily cumbersome.

[Lowlander]

I just tried on 4.1.0.1629 and can't reproduce.

[joeri_theelen]

I just had this issue again, in my current release. It is definitely a bug in 4.0.7. I'll move on to the beta release to see if it has been solved.

[joeri_theelen]

No, it is not solved in version 4.1.0.1629!

It is not difficult to reproduce:
1. create a playlist and add random songs to it;
2. manually select a couple of songs and send them to a new playlist;
3. while the songs remain selected, remove them from "this playlist only";

You'll see that the songs disappear from the initial playlist, but checking the "send to" playlist, the songs aren't there either. Then returning to the initial playlist, the songs are again there. Nothing has changed.

It has something to do with the reference or handle to the songs. It moves with the selected songs to the playlist too. Hence, when you select "remove from this playlist only", the songs in the new playlist are removed, not the playlist you initially started with (but visually, they are removed from the initial playlist, but when leaving and returning to that initial playlist, they are there again).

It would be handy to have the option to "Send to [new playlist] and remove from [current playlist]" or just "MOVE to [playlist]".

I really need this option because for library maintenance I am working on large playlists using set algebra: I select songs and require them to move to subsets of the current playlist, but keeping the current playlist and the new ones distinct (hence, the removal after the send to is crucial).

Thanks for looking into this again.

[joeri_theelen]

Because I am a programmer myself, I can almost see the origin of the bug. When you send songs to a new playlist, the handle to the current playlist becomes that new playlist. But that isn't right, because the current playlist and the one you are looking at in MediaMonkey still is your initial one. It must be easy to fix this. Thank you.

[Lowlander]

I can't reproduce so you may want to capture this in a debug log (step 4b) and send it to support: http://www.mediamonkey.com/forum/viewto ... ?f=7&t=341

[jtheelen]

Ok, thanks for the advice. I just filed a bug report, ticket HYJ-825428.

[rusty]

Thanks--I was able to replicate. Tracked at:
http://www.ventismedia.com/mantis/view.php?id=10677

-Rusty

[jtheelen]

Waiting for this issue to be fixed, this is my work-around: create the playlist you want to send the songs to first, then select the songs in an existing playlist and send them to the newly created (but already existing) playlist, then delete them in the current playlist. That works. The difference: do not create the new playlist as part of the send to operation, because the handle to the current playlist moves to the send to playlist what causes the bug.

Because I have to do this a lot, I end up preparing a lot of empty dummy playlists first, as sort of buckets waiting to send song selections to. It is not ideal, but it does the trick.

Another thing that would help me here is the drag and drop from one playlist to another. In MM3, dragging and dropping used to be a move operation. I used to be told on this forum that the drag and drop in MM4 was changed into a copy operation, and indeed, that is what is happening. Safe and good! I was also told that this behavior could be altered from a copy to a move holding down the SHIFT-key when doing the drag and drop:

http://www.mediamonkey.com/forum/viewto ... 18#p303318

This does work, but the annoying thing is that the SHIFT key has another important function when selecting songs: it triggers a range select, from the first to the second song and everything in between.

Now, try this:
- select a couple of individual songs in a playlist holding down the CTRL-key;
- drag & drop the selection to another playlist, holding down the SHIFT key to change the copy into a move.

You'll see that the use of the SHIFT-key doing the drag and drop, messes up the initial selection. It becomes a range select. You'll find yourself dragging and dropping the wrong selection of songs.

SHIFT is not the right meta-key to change the drag & drop behavior. The ALT-key would be a better choice, because both SHIFT and CTRL already have dedicated functionality when selecting songs.

Thanks for considering this.

[Lowlander]

Shift and Ctrl are standard keys also used in Windows Explorer to define if it should be copy or move. However Shift + Drag & Drop seems to be broken (Ctrl + Drag * Drop does work): http://www.ventismedia.com/mantis/view.php?id=10682

[joeri_theelen]

I don't agree with this. As a matter of fact: I just checked the working of SHIFT and CTRL in Windows Explorer. This is what they did:

SHIFT: range select, from first file to second file and everything in between
CTRL: select of multiple random files

They do not trigger the copy vs. move in my version of Windows Explorer!

But I agree that SHIFT and CTRL work the same in MM and Windows Explorer regarding the range select resp. multi-select.

The problem arises when you use the SHIFT to move a selection of songs made with the CTRL key held down (i.e. a random selection of songs in a playlist). Then, the SHIFT acts like the range select meta-key (similar to Windows Explorer) and while it is in fact triggering a move in stead of a copy in MM (nothing seems to be broken here), you'll be moving a different selection than intended, because you'll loose the multi-select made with the CTRL-key held down.

This is not an implementation problem in MM, or a bug so to speak. The problem is that the SHIFT-key is overloaded triggering two different behaviors (multi-select vs. move drag & drop) and these two don't go well together.

I strongly suggest you change the meta-key to trigger a move drag & drop in MM into the ALT-key.

[nohitter151]

I don't agree with this. As a matter of fact: I just checked the working of SHIFT and CTRL in Windows Explorer. This is what they did:

SHIFT: range select, from first file to second file and everything in between
CTRL: select of multiple random files

You're talking about Shift+Click and Ctrl+Click.

Lowlander is talking about Shift+Drag &Drop and Ctrl+Drag & Drop (to a folder). Try it in Windows explorer, it works exactly like Lowlander described.

[joeri_theelen]

You're right: pressing the SHIFT key should be done after dragging but before dropping. I didn't know that. Thanks for explaining the difference. I guess I should use Windows Explorer more (in staid of Total Commander).

[Lowlander]

And a bug has been file for the current behavior. For now you'll need to do with Cut & Paste options.

[joeri_theelen]

Ok, thanks Lowlander. But I don't think there is a bug. The drag & drop using the SHIFT meta-key works as expected in MM. It turns the default copy into a move. I just didn't know how to perform the operation correctly. As far as I am concerned, there is no bug.