Playlist: Sort by Track Number

[cmcarls]

Is there a way to sort the playlist by track number? The response to a previous thread implies that there's not. If not, adding that functionality would be incredibly beneficial.

Tracks appear to be added alphanumerically based upon the track name. Playing an album in order appears impossible. Dragging and dropping tracks to reorder the playlist as an inelegant workaround isn't available either. The problem gets pronounced when listening to tracks where the sequence is important for comprehension; such as in adding tracks from an audiobook.

Concatenating the track number and the track name into one string would perhaps be a solution to living within the alphanumeric ordering environment. Doing that on the user side by manipulating tags is onerous. But perhaps there is a way to implement it on the software side of things. The track numbers already appear to be appended to the front of the track names in the playlist.

Thanks for your work on Polaris.

[agersant]

Hello!

I agree this is a very valuable feature. It doesn't fit as-is in Polaris very well because the current API and clients are meant to be file browsers. Everything in the collection is a direct reflection of the filesystem, including sorting. Files are displayed (and queued) in alphabetical order by file path.

I do want to support the use case of users who prefer browsing files by metadata, both for navigation and display order (as mentioned in this issue). These efforts are grouped under this large ticket here: #92
The sort order (and therefore queuing order) for albums is hiding under one of the bullet points.

With these changes, you would be able to see the songs listed according to their track numbers, and queued accordingly in the playlist when pressing Queue All. Unfortunately, these changes are still a long way away (large chunk of work + I'm on a hiatus at the moment).

In the meantime, if you want to stick to Polaris, some workarounds could be:

• Renaming files so the names reflect the desired ordering (eg. TrackNumber - SongName.mp3)
• Use the fork from the @mzagrabe PR linked above. I don't want to merge this change because it doesn't align with my overall plans for Polaris, but it would be a perfectly reasonable workaround for this specific use-case.

Closing as dupe of #92

[dechamps]

I came across this issue because I experienced the same problem when I tried to play an album where the filenames had the unfortunate property of not using leading zeroes in the track number (as in, 5 foo.flac instead of 05 foo.flac). Hilarity ensued.

the current API and clients are meant to be file browsers. Everything in the collection is a direct reflection of the filesystem, including sorting. Files are displayed (and queued) in alphabetical order by file path.

Honestly, one thing that I find a bit odd about Polaris is that it can't make up its mind as to whether it's filesystem-based or tag-based:

• Navigation (left panel) is filesystem-based, and shows folder names as well as file names (without extensions though).
• Playlist order is also filesystem-based, based on lexicographical file name order.
• …but for some reason Polaris insists on keeping its own database that needs to be kept in sync (collection scan), instead of just being stateless and using the filesystem itself as its database (i.e. an actual dumb file browser).
• …and also, once items are added to the playlist, the playlist view shows the tags, not the folder/file names.

I'd really like to understand the philosophy and design principles behind all this, because right now I'm just confused. It's no wonder that the ordering of the playlist is confusing: it displays file tags, but it's ordered based on file names!

[agersant]

Great comment, thanks for taking the time to write it down. I can share some thoughts on this.

I agree the current state is muddied and not where I want things to be in the long run. A lot of this stems from decisions I made long ago, when I was only considering my own use case. As a result, the current setup is great only if your collection is organized just like mine (surprised-pikachu).

From where things are now:

• I want to revisit the current navigation system to be exclusively file-based. That means presenting it like a tree instead of multiple pages, and only showing information from the file/directory names (as opposed to metadata). This also would allow presenting search results in a much more sensible way, especially when considering advanced search syntax which has been requested several times.
• I also want to support a way to browse the collection that is entirely based on file metadata (by artist/album/genre/etc.). This would be one new top-level menu entry alongside Browse/Recent/Random.
• I want entries in the playlist to always show information from file metadata (as they already do)

Even for file-centric navigation, the collection index is essential. If we were to use the filesystem as the database, clicking Queue All from a top-level directory (or any directory with lots of nested music) would take an extremely long time. The server would have to traverse the file structure to know what songs to queue (very slow), and also read metadata from these files to know what to show in the playlist. As a data point, that would be 20 minutes instead of 1 second to queue my entire music collection.

In short, I very much agree with your points and hopefully the vision above would resolve most of them. I would love to hear what you think about these plans.

I must caveat this all by adding that I am not working on these changes at the moment. Polaris is one of several hobby projects I cycle my attention between. A lot of my Polaris time in the last couple years was spent on re-doing the Android client, which finally shipped a few months ago. The ideas listed above are the next thing on the list but I cannot give any ETA (and also am not interested in PRs for such large changes).