Raising this because some other threads look old. I’m dumbfounded that the Sonos app has no information about release dates, album credits, lyrics, artist descriptions, album descriptions, and so forth. All of the major music services have found a way to do this, surely Sonos can too. Not to mention no way of viewing the audio quality of an album (ie atmos) beforeclicking play. For Apple Music, this means that you have to research what albums are in atmos or hi res lossless, then go back to the Sonos app, search for the album, play it & then verify if it is actually playing atmos or not. This is very time consuming and a real pain in the ***.
I’m tempted to ditch Sonos soon, purely because Sonos really can’t seem to get their act together on the software front. And reading prior threads, the response seems to be to punt the responsibility to the third party service, saying there’s nothing that can be done on the Sonos side. I don’t know, maybe set up a call or two with developers from the other third party services? And hire some UX experts while you’re at it. Surely there’s some way that this can be fixed. The basic functionality of the app seems stuck with almost the same functionality it had 10 years ago, it feels like a slow dinosaur.
Anybody have any insight if Sonos has some of these features on a roadmap? Or do they just not care, which is what it seems like to me.
Page 1 / 2
Hi @jhl88
Thanks for your post!
And thank you for your feedback! We absolutely do care, and have been working on some changes - changes I can’t really talk about at present, as we do not, as a rule, comment on future features or products. Your experience is important to us, and we have been listening to feedback - it’s just that some of these changes are, well, big, and take some time to implement and test. They will take more time yet.
It should be noted, however, that some of the things you mention are indeed not under our control. I don’t know if things like release dates are supplied in the metadata, but I can see how some users would perhaps want that info available in the search results if it was.
Your point about searching and selecting high-res tracks is well taken. I've marked this thread as a feature request and it will be seen by the relevant teams for consideration.
I hope this helps.
SMAPI data does not include most of the items you are wanting:
Release date is only included for podcasts, and the apps will display that when the music service provides it.
Lyrics are in theory handled by the app, but I am not aware of any music service that actually sends lyrics data.
Lossless is in the metadata, and my app on Windows (see profile) does show which tracks are lossless before you play them, see the stars:
Qobuz displays the album release date in browse / search.
@Corry P Thanks for the reply… look forward to future app updates.
@controlav@Corry P I’m not familiar with SMAPI, but both Apple and Spotify have external facing APIs. Here they are:
What is the technical limitation for the Sonos app to connect & pull data from third party APIs like these? For Apple Music specifically, appears you can request an Album “object” that returns all of the data I mentioned (except lyrics):
And there’s a lot more data that can be pulled about artists, songs, etc in both APIs. Apple also has an “audio variant” response that details whether it’s atmos, lossless, or other formats.
There’s probably an extra cost to use it, haven’t researched it thoroughly. But if other music apps can display scrolling lyrics, I don’t see why the Sonos app can’t.
What prevents the Sonos app from connecting to API services like these? I understand it is a lot of coding work for each service… beyond that I’m not understanding what the tech issue is.
Thanks,
Josh
That would be nice if Sonos went through the Apple/Spotify API. It doesn’t. It’s the music services who code their UI using the Sonos API. That’s what allows Sonos to support over 120 music service worldwide, when other streamers only support a half dozen or so.
It’s also why, aside from things like local libraries or Sonos Radio, your beef is with the music services. They are in charge of the look and feel of their implementation in the Sonos app.
That would be nice if Sonos went through the Apple/Spotify API. It doesn’t. It’s the music services who code their UI using the Sonos API. That’s what allows Sonos to support over 120 music service worldwide, when other streamer only support a half dozen or so.
It’s also why, aside from things like local libraries or Sonos Radio, your beef is with the music services. They are in charge of the look and feel of their implementation in the Sonos app.
Why was the decision made to put the onus on the music services? It seems to me it should be the other way around. I agree with your point about sonos being the most open platform, but that shouldn’t prevent more tailored custom integrations with the biggest music services.
That would be nice if Sonos went through the Apple/Spotify API. It doesn’t. It’s the music services who code their UI using the Sonos API. That’s what allows Sonos to support over 120 music service worldwide, when other streamer only support a half dozen or so.
It’s also why, aside from things like local libraries or Sonos Radio, your beef is with the music services. They are in charge of the look and feel of their implementation in the Sonos app.
Why was the decision made to put the onus on the music services? It seems to me it should be the other way around. I agree with your point about sonos being the most open platform, but that shouldn’t prevent more tailored custom integrations with the biggest music services.
Because Sonos didn’t want to write and maintain code to 120 different APIs. They started down this path (with Rhapsody and Pandora which each had their own APIs) but it was simply not scalable, so SMAPI was born and the onus moved to each service that wanted to play, and most have done so.
Why was the decision made to put the onus on the music services? It seems to me it should be the other way around. I agree with your point about sonos being the most open platform, but that shouldn’t prevent more tailored custom integrations with the biggest music services.
Because they wanted the easiest way for music services to join, with the least amount of effort on Sonos’ part. So instead of Sonos maintaining 100’s of different implementations of individual music service API’s, they maintain one, and the music services get autonomy over which features they wish to incorporate in their implementation. It’s what allows them to support 120+ music services, whereas competitors are lucky to support 1/10th of that.
Bottom line is, if you wish to see a feature, lobby the music service. It will be far more effective in getting features you wish than lobbying here, because Sonos couldn’t make the changes even if it wanted to due to the terms of use for SMAPI.
I think it’s worth noting as well that although users see search results through the Sonos app, the app isn’t actually doing the search as I understand it, the Sonos devices are. That limits the size of software to do searching, but also means you can do voice control searches, and the device can more easily report back what it’s currently playing. I suppose that could be changed so that the Sonos app does it’s own separate, more advanced lookup using the music services API when available, but that adds a lot of complication.
I think lyrics might be hard feature to accomplish, if you want the lyrics to display in time with the music. That would require the speaker to constantly/regularly send lyric data to the Sonos app. I guess it already does this though, as you can get current runtime data from the Sonos app at any time. Anding lyrics wouldn’t be much different, assuming you can get lyric data from the streaming source.
That would be nice if Sonos went through the Apple/Spotify API. It doesn’t. It’s the music services who code their UI using the Sonos API. That’s what allows Sonos to support over 120 music service worldwide, when other streamer only support a half dozen or so.
It’s also why, aside from things like local libraries or Sonos Radio, your beef is with the music services. They are in charge of the look and feel of their implementation in the Sonos app.
Why was the decision made to put the onus on the music services? It seems to me it should be the other way around. I agree with your point about sonos being the most open platform, but that shouldn’t prevent more tailored custom integrations with the biggest music services.
Because Sonos didn’t want to write and maintain code to 120 different APIs. They started down this path (with Rhapsody and Pandora which each had their own APIs) but it was simply not scalable, so SMAPI was born and the onus moved to each service that wanted to play, and most have done so.
Not all of the 120 different APIs would need to be custom integrations. I’m specifically talking about the biggest services that most customers use. An example of punting the ball to bigger companies, which of course have little to no interest coding custom integrations for Sonos when they would prefer users to stay within their own ecosystem. What motivation do they have? I’m surprised that Spotify made the effort. If Sonos values their customers, they need to do the extra legwork to code on their side, find a way to partner instead of severing ties, etc. The fact that I’m on this forum arguing about features just goes to show how poorly managed their business is. They don’t even bother responding to direct contact emails, forcing people to use these crappy forums.
The fact you are on this forum is proof you are not listening to reason. Because if you were, YOU'D BE COMPLAINING TO APPLE AND SPOTIFY!!!!!
The fact you are on this forum is proof you are not listening to reason. Because if you were, YOU'D BE COMPLAINING TO APPLE AND SPOTIFY!!!!!
This is exactly why I’m complaining. I shouldn’t have to, that’s on Sonos to do the legwork on behalf of their customers. I’m writing this here, because my opinions are about Sonos & I want them to “hear” it. If I could play atmos through airplay, I would then only use the Sonos app for speaker grouping & use the apple app (or other) for music nerd info browsing, scrolling lyrics, etc. As it is, you are forced to use the Sonos app to play atmos. This might be on Apple or limitations of airplay streaming. Regardless, because of that the user is now required to use the Sonos app. Considering that Sonos is pushing their hardware as cutting edge atmos capable, it’s ridiculous how terrible their software user experience is. Every time I use it, I’m incredibly frustrated.
I’m attaching the current artist Sonos app experience via apple. What dates were the albums released? Are these all albums or EPS or singles or live or compilations? Are they hi res or atmos albums? How about a short bio of the artist? Photos of the artist? Related artists? Members of a band? Most popular songs / albums? None of these questions are answered in the Sonos app. Scrolling lyrics? You can dream Sonos customer, you can dream. It might be on the roadmap 5 years from now. Static lyrics? Also no. The only info displayed on the Sonos app is the title of the artist and a grid of record covers. As a fun bonus, searching for REM or R.E.M didn’t yield any results. I had to search for an album title instead just to get to the artist page.
And yes, I will go to apple and complain because I’m now curious what the response will be on their side, if there even is one. However, the whole reason this complaining continues here is because THE SONOS APP SUCKS.
PS, hardware volume controls on iphones no longer work, so you are also forced to open the Sonos app to adjust the volume.
So “it might be on Apple”, but here you are? I rest my case. Again, Apple is responsible for their appearance and functionality within the Sonos app. Sonos couldn’t change it if they wanted to, and have no financial leverage with Apple, unlike those who pay for the subscriptions.
SO GO COMPLAIN TO APPLE!!!!!!!
As a sociology experiment, the dynamic at work here is absolutely baffling. A user will spend hours of their time and endless posts complaining at a place which cannot solve their problem, and yet refuse to spend any time posting at the one place which can fix their problem, because . . . reasons.
Freud would have a field day.
So, the lesson I am to take here is that Sonos prefers their customers to complain to other large tech companies for them. Again, in my opinion this is punting the ball. I will do so as instructed, and report back.
So “it might be on Apple”, but here you are? I rest my case. Again, Apple is responsible for their appearance and functionality within the Sonos app. Sonos couldn’t change it if they wanted to, and have no financial leverage with Apple, unlike those who pay for the subscriptions.
SO GO COMPLAIN TO APPLE!!!!!!!
Sonos couldn’t change it if they wanted to? This is the defense? Anyways, I will complain to Apple too! I’m curious to see if either company gets off their ass now.
Sonos couldn’t change it if they wanted to? This is the defense? Anyways, I will complain to Apple too! I’m curious to see if either company gets off their ass now.
So, the lesson I am to take here is that Sonos prefers their customers to complain to other large tech companies for them. Again, in my opinion this is punting the ball. I will do so as instructed, and report back.
No, Sonos knows it has no financial leverage with Apple, so their lobbying will mean nothing until subscribers start requesting features too.
So, the lesson I am to take here is that Sonos prefers their customers to complain to other large tech companies for them. Again, in my opinion this is punting the ball. I will do so as instructed, and report back.
No, Sonos knows it has no financial leverage with Apple, so their lobbying will mean nothing until subscribers start requesting features too.
Do you know if Sonos has attempted to? Or do they just assume they won’t get anywhere?
Do you know if Sonos has attempted to? Or do they just assume they won’t get anywhere?
They have stated in the past that although they pass along requests, the best way to lobby for features is to lobby the music services directly. They’ve also repeatedly stated there is no financial exchange by either party for integrating a service into the Sonos app, so they have no leverage.
If I’m understanding correctly, the only parameters available via the playback object SOAP requests & hero views are these:
Artist
-Name
-ImageURL (artist photo)
-ID
-Tags (only option is to display Explicit or not)
Album
-Name
-Artist
-ImageURL (album cover photo)
-ID
-Tags (only option is to display Explicit or not)
Track
-Name
-Track number
-Artist
-Album
So even if a music service wants to display other types of data, whether it’s Apple or not, they are restricted to these parameters. Correct? Again, here are some parameters that I think would be nice to have but don’t appear to be included in the Sonos API:
-Album release date
-Album description or review
- Album credits (producer, band members, etc)
- Audio quality (Atmos, lossless, etc). There is an Atmos “badge” on a track once it starts playing, but no option to view before playing.
- Artist bio
- Release type (album, single, live, compilation etc). There is an option to create container lists of these on an artist object, but once viewing an album type, it doesn’t display any info about it.
- Direct link to artist from album. There is a link buried under “more” in the sub menu, but it takes some effort to find that.
- Track lyrics
Maybe some of these can be passed via a generic container type, but that seems to be restricted to a list format, not text.
I also took a quick look at integrations with Tidal / Amazon, they are a bit better at the Artist level with container lists of most popular and release types. Spotify connects directly to the app, but then Spotify doesn’t provide Atmos or lossless.
Anyways, I’ll follow up if there is any response on the apple support forum. None so far.
Your metadata list is reasonably accurate, but SMAPI does expose lossless tracks when enumerating (Sonos app does not display this, mine does), and SMAPI includes lyrics support (though I’ve never seen a music service that generates it). There is also a Description field for podcasts (only).
The Atmos badge (and the other “high-res” badges) are only displayed after streaming has started as the system has to determine what quality it can play over the transport, that data is not in the metadata (but in the stream).
Your metadata list is reasonably accurate, but SMAPI does expose lossless tracks when enumerating (Sonos app does not display this, mine does), and SMAPI includes lyrics support (though I’ve never seen a music service that generates it). There is also a Description field for podcasts (only).
The Atmos badge (and the other “high-res” badges) are only displayed after streaming has started as the system has to determine what quality it can play over the transport, that data is not in the metadata (but in the stream).
Thanks, that clarifies the atmos hi res badge display issue. However, from a user experience perspective, I would like to see at a glance whether or not an album or songs are intended to be in Dolby atmos / lossless or not. If the Sonos app badges don’t officially confirm the format while playing, then that is a problem to troubleshoot the hardware & software setup. It just seems to me that the approach is backwards.
I think apple has three audio quality categories: Atmos, Hi Res Lossless, Lossless. Couldn’t this text or flags be passed to the Sonos API for display of icons or text? It would require a separate parameter in the Sonos API, if I’m understanding it correctly. Yes, it’s important to verify technically exactly what the audio quality is while streaming on specific speakers. But why should that prevent categorizing the intended audio format(s) in the Sonos app as well?
