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

Would it not have been a better use of everyone's time to just ignore this thread?
Done.

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.

The system, for me and I suggest the majority of users, is perfect for most as a wireless home music service. I can move between rooms and controllers at ease and add or remove tracks to queues, have different music in different rooms and move queues between rooms, whilst others can also so the same and the queue will show the same for every controller linked to that Sonos system. I can take calls on my phone without it interrupting the music for me or others. I can use an tablet or pc to make changes too. It's this functionality that is so popular for the Sonos system as well as making it work with 3rd party dumb controllers such as Scenic Nuimo and iport express, to name but a few. Nobody can leave the house and destroy the queue, nor can a flat phone or tablet battery stop the music. These are massive plusses. Add that all speakers Sonos have produced since their first model, can still be used as part of a system over 15 years later. and you see why we like this "flawed" system. 🙂

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.

The number of people with over 65,000 tracks is minimal

It simply doesn’t matter - Sonos support loads of third party services where the take-up is minimal - if it’s supported, support it well. The fact is:

1) SMB 1.0 is horrendously outdated
2) index file is not required

The real business reason behind the decision is to push people towards streaming services to please those vendors, out of fear that those with large libraries attained those libraries by illegally pirating.

None of which matters. The indexed SMB 1.0 file share sucks big time. Most IT environments have SMB 1.0 disabled due to vulnerabilities. It is simply crap, and trying to defend it to tell users how they should be using the product .... sounds more like Bose than Sonos.

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.

The real business reason behind the decision is to push people towards streaming services to please those vendors, out of fear that those with large libraries attained those libraries by illegally pirating.


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.

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

1) SMB 1.0 is horrendously outdated
2) index file is not required
So don't use them.... Use a NAS that supports SMB 2.0 and above, run an audio server on it and then use (e.g.) Hifi Cast to cast the music to the Sonos player. IIRC Hifi Cast costs about £1.70 to remove the ads.
I'm not happy about Sonos software, either, but workable alternatives are now available - so surely it's time to move on.

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=amun]
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.

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?