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

Good question to ask. A big part of this design is to keep consistency across all controllers. The music index is only built the one time by players (until it's re-indexed), and then all controllers in the house show the same index. If it were stored on the controllers, they'd either have to index individually, one controller at a time, or possibly the players could make an index and then push it to the controllers, but currently, that whole process is read-only, no writing.

In part, the answer to the question "why" really is going to come down to "when we designed it, this seemed like the best option." There are certainly going to be lots of reasons involved and I don't know all of them. Lately, Sonos devices are more Internet-connected than ever, so there's always a chance that you'll see some change in the future to indexing and local libraries.

I can't speak to future plans that haven't been announced, but you never know what might happen. There was a time Sonos technicians manually created and curated the list of Internet radio stations that players displayed, now that's done by a music service.

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.

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.

IF there is issues with controllers accessing secure network shares, The Sonos speaker(s) can act as pass through servers (ie call a share for the listing of a given share and pass the data through to the controller app.)

To address a few of the issues/limitations called out in this thread:

- Richer metadata benefits streaming services, not just music stored on a network share. Artist art, release year/date, copyright/publisher info, etc. is all metadata that most streaming services already make available.

- A "last updated" timestamp stored on the speaker(s) would ensure that every time a controller connects/checks in it is as current as possible

- I expect more people have more speakers than controller apps so it would less effort/network traffic to keep the controllers in sync

- if Sonos insists on storing library data on the speakers a richer set of metadata could also be stored on the controller(s)

- metadata on the controller has no limitations other than the device. This would allow Sonos to keep up with richer native apps and, theoretically, deliver metadata as rich as roon, without the need for hardware upgrades.

- caching metadata/art on the controller would make browsing libraries a WAY better experience. In line with accessing a native library.

- If Sonos is going to stay ahead of the pack keeping their app best in class is probably a good idea to ensure metadata is as rich as possible. Apps that provide a richer experience and download missing art/tags is the norm these days, even the better free apps do this.

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

Cheers

FYI, the OP is correct - this is a fundementally poor and very flawed implementation.
I think that's a bit unfair. I can't say that I'm happy about the problems with handling large local libraries, but there seem to be quite understandable historic reasons for it. I would imagine that such large local libraries weren't considered that likely, and that it was considered important not to write the index onto user storage, with all the potential pitfalls that entailed. For speed purposes as well, the chosen approach was considered the most suitable back in the early 2000s. Time moves on.
I have been very critical of some of the solutions offered (e.g. the implementation of Plex on Sonos) but some of the solutions offered above are now very good. I can use the Hifi cast app to cast music from my NAS to my Sonos players, with none of the restrictions of the Sonos provided software - this gets me around the limit on store that was stopping me adding more music to my library. Even if the Sonos kit goes totally belly up, I have now tried using Chromecast Audio devices, either as a line input to a Play 5 or as a direct input to an AV amp - and they work fine. Google have now discontinued these devices, presumably because they undermine their speaker range, but other similar devices are probably available.
Things are much better now than they were a couple of years ago, IMHO.

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

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.

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.

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

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.

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.

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.

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