The New Sonos App and Future Feature Updates

Aug 6 update ruined any progress that was made. Get this thing working or let me go back to legacy. I’m typing this while I hear all my speakers going in and out of connectivity while playing. Give us a date for the legacy app. I’m sick of checking. 

Try using the Windows or Mac version of the Sonos app which you can download from the Sonos website. (Google it if you can’t find the download page.) That will usually let you update your system where the phone fails.

You can prove to yourself where your data lives (Sonos box, app, cloud) by installing the app on other devices, using the (vastly superior) Sonos desktop app or 3rd party controller, disabling your wifi, factory-resetting your system, etc, but… Sonos stores everything - Sonos playlists, local library meta info, etc. on the Sonos players, not the app (with data shared/propagated to all your Sonos speakers/boxes).

I did see a rumor here once that “recently played” data was actually stored offsite in your Sonos account, but of course it’s stored locally, because it would be the the dumbest engineering decision imaginable (except from a customer-data-mining perspective) to store “ephemeral local data for a system with local storage” in the cloud.

no of course not, spent too much $$ to do that - I just said it out of frustration
I will persevere and hopefully fix it, but I need to find some solid hours when I can figure it out…, which shouldn’t be the case in a product of this caliber
 

So if it’s just a rumour why is the app unable to show me recently played when all access to Sonos.com is blocked on my network. ie the Sonos cloud is unavailable?

As you think it’s a dumb engineering decision, where would you store it so that my phone, tablet, other family members tablets, the online web player and 3rd party controllers using the api can all show the same data?

Surely not a copy in every Sonos playback device with write lifetime limited storage. Or should every controller have a unique view so when I use a different controller I have a completely different list of recently played? That would be annoying.

There are far more useful purposes for it being stored centrally for controllers which are randomly switched on/running to show the same view than there is for data mining. Details of what you play are already available to Sonos as you play it, no additional benefit wasting storage or processing time harvesting a list of recently played items which a short duplicate.

OK, so I’m making a guess here about how Sonos stores other local data eg. Local library meta info and Sonos playlists, both of which have a fairly long lifespan. They’re probably propagated to all your Sonos boxes, because if you have two Sonos speakers and turn one of them off, you don’t have to wait ages for the library to re-scan or playlists to re-sync. You play local music/playlists “from your Sonos system”. So we can discount app or individual speaker storage, which leaves the option of cloud or “Sonos boxes all sync’d together” storage. Sonos boxes will happily store meta info for several thousand tracks, so recently-played (which is basically “a playlist that can handle individual tracks or whole albums as an entry type”) isn’t much extra data.

Recently-played data has always been a bit flaky (the app currently doesn’t include local library plays and only seems to track half of my plays from Qobuz, and they never added it to the desktop controller), so I wouldn’t be completely surprised if Sonos had ended up storing that info differently from your Sonos playlists.

As far as I’m concerned, any unnecessary connection between one of my Sonos boxes or controllers and the internet (which is anything - setup, play history, track selection - that doesn’t involve a music service hosted outside my house) is a “dumb engineering decision”. But I still think of Sonos as a “music system for my house” because that’s what I bought into - I’m starting to think they have a different vision for the product.

Plenty of home automation products require a connection to the internet to do “interactions between two devices on your home network” (and therefore require the company who sold you it to still be in business and running their servers) because “reasons”. The fact that the Sonos web player currently contacts a server running on Sonos servers (for technical reasons or those “I forgot to turn off the music when I left the house” use-cases) rather than a small web server on your Sonos system (eg. the way your router config app works) is very interesting. But Sonos do have a recent history of making some extremely, er, “interesting” engineering decisions recently.

I’m with you on the cloud connection for things I consider essential. I don’t have a use for an external web controller, but I can see it as an example to show how the api can be used. In a commercial environment if they just wanted a controller to play/group things on a restricted device that only has a browser it could work.

I did have a poke around in the web controller and you can see the messages that get sent and received through the websocket. In the code there is config for whether it is a local or remote controller. I’d guess if set to local, then it will connect to the devices across the lan rather than the cloud api. Maybe the idea longer term is to put a wrapper around it and make it downloadable to replace the current desktop apps.

No idea whether it was my OS and/or browser security or a bug, but while it would group players and you could seem them grouped locally, the interface didn’t update.

The local library is definitely on the players. Asking for a library update causes on of them to extra the metadata into database files. Whether it’s just copied or diff-synced between players I’ve no idea but they all get a copy. Playlists may sense to be the same to me, although I’ve never used them, so don’t know how often people would change them. Many of them the guys who write 3rd party controllers will probably know. Favourites could be either, most of my favourites are against streaming services so it’s easy to find again :)

Certainly, creating a “desktop” controller that’s just a “bundled web app” is a no-brainer, the sort of thing Sonos should have done years ago instead of endlessly refusing to learn about cross-platform development and producing wildly different desktop and mobile controllers.

Although the current desktop client (and previous mobile app, obviously) beats the new mobile app for features and “clean intuitive design”, I’d probably be happy with a desktop client that was just “the same mobile client bundled as a Windows app but without setup options because reasons”, even if it meant killing some of the really useful desktop-only features (eg. error logs showing network interruptions and skipped tracks, sensibly-ordered favorites, local library browsing) and suffering the busy confusing “sliding panel” new UI design.

I presume Sonos do something in the Apple App Store to prevent their official iPhone/iPad controller software from appearing on an Apple M-whatever silicon Mac… if they made the iPad one available, you should be able to run it as is, unless it flouts some rules that disallow it. That would be the easiest way to create a functional Mac controller perhaps. 

I use this for the Naim/Focal app and that seems to work ok. 

Apple developer rules (which they have been clamping down on over the past year or so) define a number of aspects regards the UI, how it should function etc … don’t follow their guidelines then they refuse to put your app in the App store  …. A good android UI is rarely identical to a good Apple iOS UI ...