mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #1545] Sorting isn't applied #698
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#698
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @acid-sun on GitHub (Aug 21, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1545
Playlist playback order is broken if the playlist is not sorted by default.
Description
If you sort playlist by add date and start play, play order is reverse.
Version
librespot 0.6.0-dev
78ce118(Built on 2025-08-21, Build ID: ocjahGFT, Profile: release)How to reproduce
Host (what you are running
librespoton):Additional context
Early versions don't have this problem ([librespot @ 383a6f6]).
@photovoltex commented on GitHub (Aug 21, 2025):
That's probably because we currently don't use the values that are sent for sorting and such. Probably not a bug and more a missing implementation/feature?
@acid-sun commented on GitHub (Oct 21, 2025):
Commit
5839b36break order and queue.Before
5839b36, work correct.@photovoltex commented on GitHub (Oct 22, 2025):
Jep, that's the big rework of the connect handling. I recently saw how the sorting is retrieved in the play command, but it's not something we can easily apply currently unless I'm missing something on my end there.
@PinguDEV-original commented on GitHub (Feb 4, 2026):
Is there anything happening regarding this? It'd be really cool to see that implemented
@photovoltex commented on GitHub (Feb 9, 2026):
I think implementing this might be quite a hassle as the metadata of an context only gives us the details how you can sort it. So something like "name asc". As we are only a library we only keep necessary info in context and don't query for anymore info then necessary. Because of that we only have the uri of a track to work with.
Supporting sorting would mean, we find out if the context andpoint has a query or header parameter where you can provide the sorting info, so that the context is already returned. Or we would need to query all track metadata and sort them ourself.
Feel free to dig into the topic and contribute to it, but that's the general details I remember when I work on the connect implementation.