Are you still using the old classical search in the App or the new search facility that’s being rolled out to users? The new search results clearly distinguishes between Albums and Singles etc. See screenshot below:

I did not see that, it is indeed much better. If I click through to the artist, the view is still the old unsorted one. But it is far less annoying since the improvements to search.

Ideally the artist display would be similarly split. And the sort order IMO should default to chronological.

Yes, I would like to see the various areas display in chronological descending release-date order too, but I guess there isn’t too much call for these things. I’ve seen the request before however, but that was quite some time ago.

Sonos never sort third-party data, for multiple good reasons. In this particular case it is because they have no idea what the release date of anything is.

Content can only be sorted by the service provider, as only they have the data to do so. (There are also technical issues regarding large collection types).

As a software developer that doesn’t make much sense. Retrieving data and displaying data are two different operations and they can (and should) be treated separately in the application. I can think of at least 3 different approaches that could be taken, even if the collection is large (and I doubt any artist has a collection of releases that could be considered to be large enough to need special consideration).

For example, there is a sort order flag that can be used on the Apple Music API directly: https://developer.apple.com/forums/thread/653885

Or alternatively, the release dates could be queried in subsequent lookups and cached. Apple Music has something like 90M songs. This might equate to 50M albums and releases. So even if caching every release date, it barely qualifies as big data. Depending on how the Apple Music API is called, it could be sorted server-side or the data could be provided to the app to be sorted client-side. I could likely mock something up pretty quickly, and I’m sure Sonos have excellent developers who could also do this.

Sorry if that comes across as argumentative, I appreciate the input. It’s just that I searched the forums and saw similar responses to the same question. There’s no technical reason that data cannot be presented in any way it is needed.

Luckily, there is now a better search results display so it goes some way towards improving navigation.

The Apple API is not relevant here: Sonos support over 90 music services, and the only API that matters is SMAPI.

If you read the SMAPI spec you can see that releaseDate is only included for podcasts:

https://devdocs.sonos.com/docs/smapi-object-types

If, as you point out, if you have 50M albums in a database any sorting must be done server-side (and then delivered to the client via pagination), no app is going to download 50m items and then sort them.

SMAPI has no provisions for server-side sorting, though any music service could easily add a special collection to their subtree that says “Albums sorted by release date” or whatever. To my knowledge none have.

TL;DR in-app sorting remains supremely unlikely.

That makes me even more puzzled. The Sonos Music API is owned and developed by Sonos. Saying that a controller feature is not possible because a feature is not implemented in the API implies that the API is somehow beyond the control of Sonos. As with any API-driven app, new features usually require coordinated changes in both the client and the API.

I was just sketching out an alternative approach to sorting in broad terms. Clearly a cache is only useful if it is likely to be hit, which did not imply storing 50M data points client side. The flow would be something like 1) client obtains releases from the API, 2) client requests release dates from the server-side cache in a single call, 3) optionally the client caches the results locally 4) client sorts the data obtained in step 1.

It might be that holes can be picked in that flow (and given that Sonos owns the SMAPI, it doesn’t even make sense to do it this way) but that’s not the point. It is always possible to organise data in any way we need for it to be useful. If it wasn’t I’d be out of a job as a software engineer. :)

Sonos would have to extend their API definition, then get some music services to implement it on their endpoints, then update the Sonos app to use the new API. All very possible, but sorting has been asked for many times before to no effect.

Fair enough. Thanks for taking the time to talk. Pretty good dev docs BTW. I’m almost inspired to try out the APIs. :)