plman.AddLocations bug

[regorxxx]

This may be also present on JSP (?) @marc2k3

Current plman.AddLocations implementation has a problem, it silently fails when adding the handle list if the index is wrong AFTER calling the method.

1. Create an empty playlist: const idx = plman.CreatePlaylist(plman.PlaylistCount, 'Test');
2. Load a playlist file with 3K tracks (so it takes some time). test.zip const path = "my_test_path..."; plman.AddLocations(idx , [path], true);
3. Close a playlist on UI with an index lower than idx variable.
4. Whenever the async loading finishes, no tracks are sent to the desired playlist 'Test' but...
   • If "Test" is the last playlist, then tracks are dropped since "idx" variable points to a playlist number no longer valid (and it doesn't crash since the check is only performed when calling the method).
   • If there are more playlists with higher indexes, then the tracks are sent to the wrong playlist (now having the same index than "idx" var).
   • There is no way to manually fix this on script level, since the async process can not be aborted or pointed to the new idx.

Both behaviors are shown on this gif. Note I reproduced the problem with my manager, but it can be done with those 2 lines alone.

I know the current implementation of playlists is a mess, because they don't have a UUID to track them... but this behavior opens the door to a lot of problems. Also it doesn't follow foobar native behavior, which manages the situation fine: i.e. if you manually load a playlist (drag and drop) anywhere, and you mess with the other playlists, things are loaded fine.

Playlist should be tracked during the async loading to ensure the tracks are sent to the initial playlist, and not to another one, no matter whatever happens in the process.

Another workaround would be a new method returning a promise, so the script can do whatever we want with the tracks...

[marc2k3]

Yeah, it's definitely a bug. I'll be fixing this in JSP later on today/tomorrow.