Closed telekineticyeti closed 1 year ago
I'm unable to reproduce this on my side. Are you accessing your Navidrome instance through a reverse proxy?
Yes, I am using a reverse proxy - I'll give it a go without the proxy and see what happens
My educated guses is that you may be running into a HTTP 414 error (URI too long) when trying to save. Sonixd re-creates the playlist when reordering tracks in the playlist, which appends each songId into the url query string. Navidrome uses UUID's for ids (e.g. 7ec3634094e7594670ec27eb6362a5ba
) which are quite long, so any time you save a playlist, it creates a fairly long query string which is sent to the API.
If this is the case, you may need to update your reverse proxy configuration. Nginx as an example
I can confirm that with the proxy taken out of the equation, the defect doesn't occur and Sonixd functions as expected. Thanks for the insight! I'll close this issue.
Describe the bug I am using Navidrome 0.49.3 (8b93962f). Adding tracks to a playlist works mostly as intended, however if you open the playlist in Sonixd and attempt to move or remove tracks, the playlist save will fail and remove almost all tracks from the playlist. This seems to only happen in playlists with around 200 or more tracks.
To Reproduce Steps to reproduce the behavior:
Expected behavior Editing tracks in an existing playlist should not remove unrelated tracks from the playlist.
Screenshots
The playlist being edited with 202 tracks:
First toast message recieved when removing a single track and clicking save:
Second toast message recieved when trying to save again:
The playlist state after the second save attempt. All tracks removed (see header), but some still visible in the playlist grid. These dissapear when navigating away from the playlist and returning to it again:
Desktop (please complete the following information):
Additional context I suspect there is some kind of pagination of the API request happening here on Navidrome's part, however I'm not able to confirm this. I had another playlist with 355 tracks that was reduced to 55 tracks when reproducing this defect on it. The 55 tracks that remained were the last 55 tracks at the bottom of the playlist.
It's probably worth noting that attempting to add greater than 100 tracks to a playlist at once tends to fail, despite a toast message indicating that the operation succeeded. However, this is probably worth submitting as a seperate bug as the behaviour is not as detrimental as this one.