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

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.

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.

But come one, how many people have music across 16 shares, but not enough to breach the 65k limit?

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. In fairness, a solution like Roon is very resource-heavy and works best when run from an SSD drive - all things which weren't available when Sonos was first being developed.

I understand there are ways around the limit, or the requirement for SMB v1 (which Microsoft deprecated about 5 years ago), by using Roon or a DLNA solution. But the fact that these are not supported officially is annoying to say the least.

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.

Clever theory, except the limit existed long before streaming services even existed, and was actually increased after Sonos added the first streaming service, not decreased. Nice try, though.

Again, your logic doesn’t matter, the decision is a business one to not upgrade the 2003 SMB 1 stack, which every other device has surpassed. They don’t want users having better file share capabilities - it’s simply not on their agenda - but they sell it as supporting this, even though it only scrapes the bare minimum compared to every other vendor. It is an appalling implementation, whether you like it or not, accept it or not, or write it off as ‘meh very few people use it’

Literally all the controller needs to do is browse the directory, create a json playlist and pass this tiny tiny text file to the speaker. The speaker then establishes a SMB session to the server to source those files. It’s that simple, easy to develop and requires no speaker stored index. It has nothing to do with speed - that is a lie. It is bad software, plain and simple.

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.

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.

And as far as my logic not mattering, it certainly matters when you claim the track limit is used to push people towards streaming when the track limit existed long before streaming services were in existence. As I said, your theory is flawed.

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.

Please remember to stay courteous everyone. I've removed a few comments that are inappropriate via our community code of conduct. There is no need to attack other users or call them names. I know you can all have a polite discussion while disagreeing.

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...

I'm not sure I am following. "It" is the index? By 'remotely' you mean on the phone or PC controlling Sonos?
How do all the competitors that do not store indices on the speakers manage it, then?
I'd point you to ratty's posts on the subject, who is far more knowledgeable than I...