On the 65k limit: why do speakers index music? It just seems incredibly poor design!

Hey, another idea - open source the non-proprietary code for the app. This would allow the community to contribute rather than just complain...


Right, and become another Squeezebox "success story". :8

Squeezebox came and went before I got a chance to try it (which supports your point I guess.) That said, I am fairly certain that an architectural change that would be transparent to 99% of users, outside of the performance benefits and upside of potentially richer metadata would not change Sonos so much as enhance it, imo.

You do know they have an API that the "community" can and does use, right?

I was not aware. Thanks for raising. I did a quick search for 3rd party android apps a couple fo days ago and came up dry. Are you aware of any poweamp type players that work with sonos?

Thanks

This is a really easy problem to solve. Not sure why Sonos doesn't address. Network share paths can be stored on the controller app (rather than full library metadata). An active playlist , can also be stored on teh speaker, with the necessary metadata, to ensure a controller app going offline doesn't interrupt playback. [...]
That is already the case. The controller app is purely a remote control, all data ('My Sonos', settings, playlists, favorite radio stations etc.) is stored on the speakers.

The SMB 1.0 issue keeps getting less and less important, when you can implement an SMB 1.0 gateway to any network file system for under $50 and 20 minutes using a Raspberry Pi 3A+. It just isn't worth the massive effort and possible functionality loss to upgrade Sonos to SMB 2 for the few folks it would impact.

Same with thew 65K limit, so may work-arounds are available that Sonos just doesn't see the need to change it. And as said above the number of folks needing it is continually dropping.

Plenty of other issues impact more folks, and cause more unhappiness that Sonos is going to make priorities. I see no reasonable hope that these two are ever going away unless they get tacked onto a massive firmware revision that Sonos does for another reason.

The app contacts the players, and pulls the index every time. It's a small html file that's text only.


I'm gonna venture a guess that it's an XML file, not html. Today, of course, it would be done using JSON, but in 2002, XML was the thing...

Blah, blah, blah, stuff about SMB.


This thread isn't even about SMB, it's about the track limit. Please try to stay on topic.


Yes, it is, because SMB is what they use to access external file shares and doesn’t require an index to function. The limit is 100% artificial and intentional - the client side index is not required and does not offer any speed improvements. I have worked on an enterprise grade embedded Linux NAS product and I know this.

The fact is access to file shares is sold as a prime feature, that is MISS-SELLING plain and simple. I don’t care if you agree or respond, it is simply true. Sonos is not a NAS supporting product. If it was, they would have also supported afp and nfs.

It has nothing to do with speed - that is a lie. It is bad software, plain and simple.Perhaps you'd care to hail a passing DeLorean and transport yourself back to 2002. I suspect you'd find that the 'truths' which pertained then were rather different.

But come one, how many people have music across 16 shares, but not enough to breach the 65k limit?No idea, but that's a fundamental part of the design. (I only use 5 shares at present.)

It seems it mostly comes down to Sonos' decision of having a player-based, rather than server-based (like Roon) or controller-based (like Chromecast) solution.

And in that Sonos was reassuringly forward looking. A player-centric architecture is far more scalable and robust. Players can be independent. Controllers can control any player(s) or none.

Consider all the frustrations expressed about Apple's Airplay, which requires a stream to loop out and back via a live user device.

By the way, although Chromecast is also able to accept a 'cast' stream via a user device its success is probably owed to the fact that a stream can be 'cast off' and retrieved directly from the source by the Chromecast itself.

If I set a playlist of local content on my phone, then my phone dies, goes out of range, is destroyed by aliens or whatever, the Sonos speakers will still play that playlist even after losing connection to the phone. Is this correct?Yes.

How about a playlist from Tidal or Spotify? If I make one on the go, or load one I had previously saved, will Sonos continue to play it even after the phone dies or goes out of range?

Yes.

You have somehow yet to grasp the fact that controllers are in effect entirely optional. They store next to nothing, other than the identity of the system. They can come, they can go. When an alarm fires, for example, it's a player which is initiating the action. When someone shouts at Alexa, the instruction is processed in the cloud and comes back to the player for execution.

As to the original query "why do speakers index music?", the origins of this architecture have already been explained by a Sonos representative. Speed -- time to music -- was a key driver. There's a major difference in response time between fetching a few kB or MB of index from RAM, and having to potentially retrieve, collate and sort metadata from up to 16 separate network storage locations (Sonos supports up to 16 shares), many of which could have spun disks down when idle.

There is also a big contradiction in your line of reasoning: the advantage of setting a playlist and let it play even if the phone dies applies to local content only.
100% incorrect. Controllers instruct players. Players fetch the music data. Controllers, assuming they're still around, periodically check in with the players otherwise they only react to event notifications.

I'll admit I am confused now.

If I set a playlist of local content on my phone, then my phone dies, goes out of range, is destroyed by aliens or whatever, the Sonos speakers will still play that playlist even after losing connection to the phone. Is this correct?

How about a playlist from Tidal or Spotify? If I make one on the go, or load one I had previously saved, will Sonos continue to play it even after the phone dies or goes out of range?

[quote=YetAnotherLondonder]
Such as? What pitfalls?
Pretty obvious, surely - if it's written locally then the developer has complete control - if it's written remotely then the developer has all the problems of whether the index is available, whether the remote stroage allows access - all sorts of things that directly affect the potential reliability of the system - and therefore the support effort needed.


For speed purposes as well, the chosen approach was considered the most suitable back in the early 2000s.
How so? The index is stored on the Sonos device; only at the very beginning did a Sonos device (the ipod-like CR100) control the speakers....
It takes time to develop systems - it seems likely that the design criteria, limitations and the way around those limitations was decided two or three years before launch. Years after that, technology changed immensely and Sonos have had to balance supporting newer tech (phones, tablets, etc) with backwards compatibility. I've criticised many things about their software decisions in the past, but their attempts to keep older kit working should receive some praise, IMHO.

There is also a big contradiction in your line of reasoning: the advantage of setting a playlist and let it play even if the phone dies applies to local content only.
100% incorrect. Controllers instruct players. Players fetch the music data. Controllers, assuming they're still around, periodically check in with the players otherwise they only react to event notifications.

To the OP. But it's not just curiosity is it? You are taking a pop at what you see is a "flawed design" because it does not fit your use case. The number of people with over 65,000 tracks is minimal, and yes there are workarounds now.

Mmm, no, not quite. Like I said above, if Microsoft Word imposed a semi-arbitrary limit on the number of pages a document can contain, I'd still see it as flawed design, even if the limit didn't affect me in the slightest.

My reservation with using a non-officially supported solution to get round this limit is that, well, it's not supported, so, should it not work, Sonos would tell me to suck it up. I say this because I have been burnt with Chromecast speakers that are so buggy they are practically unusable and I'm considering returning them and replacing them with another system; before I decide whether this system is Sonos or else, I want to be 200% sure I understand what works and what doesn't. But that is a separate topic.

If I understand correctly, most of the plusses you mention do not require the index to be stored on the speakers; the key plus of storing the index on the speakers seems to be that you can set a playlist from a device (eg a phone), and the speakers will continue to play it even if the device is switched off or goes out of range. For how many people is this so important? Do you need your pets to listen to a specific playlist when you leave the house? :) How many times has your phone or tablet died, while you were home, with so little notice that you couldn't charge it?

You mention many of the plusses which make you like Sonos but, again, most of these do not require the index to be stored on the speaker. If I decide to go for Sonos, especially after the bad experience with Chromecast, it will be because of the hope that the wider adoption should mean it's more likely that the firmware will continue to be updated and that the system has been tested more thoroughly with Tidal and the other apps. Sound-wise, I prefer my Chromecast, but speakers which sound great but which you need to reset and reconfigure every other day are useless.

There is also a big contradiction in your line of reasoning: the advantage of setting a playlist and let it play even if the phone dies applies to local content only. AFAIK it doesn't apply to streaming content from Tidal or Spotify (the speakers certainly do not index the Tidal or Spotify catalogues); you have all been shouting from the rooftops that most people stream from the internet nowadays, so it's a contradiction to say that being able to switch off the phone is a big advantage, if that only applies to local music, which so few people use nowadays.