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

@chicks, Sonos tech support confirmed via email that Sonos doesn't work with dlna servers. So what they meant is that Sonos doesn't officially support it and won't help you if things go wrong, but there are dlna solutions which work with Sonos? I had read that Subsonic and the Synology music app work with Sonos, for example.

@chicks, Sonos tech support confirmed via email that Sonos doesn't work with dlna servers. So what they meant is that Sonos doesn't officially support it and won't help you if things go wrong, but there are dlna solutions which work with Sonos? I had read that Subsonic and the Synology music app work with Sonos, for example.
Yes, Subsonic works with Sonos. I've been using it for over three years. You'll need a premium subscription ($12/year).

http://www.subsonic.org/pages/sonos.jsp

They don’t officially support them, but Hi-Fi Cast, BubbleUPnP, and other apps work very well connecting my Twonky NAS to my Sonos speakers. Hi-Fi Cast even works nicely on my ChromeBox.

Correct. The app contacts the players, and pulls the index every time. It's a small html file that's text only. Because it has a size limit too, we know it's not going to ever be large enough to be slow.


FYI, the OP is correct - this is a fundementally poor and very flawed implementation. Putting aside sonos using the horrendously outdated 2003 SMB 1.0 protocol, the fact is, it is a browsable directory file sharing protocol no different to browsing a network share on a computer. There is literally zero point to having an index at all, as most music libraries are stored in artist, album folders. The user could browse the directory live on the controller, then the controller sends the filepath to the speaker.

But Sonos will lie and say ‘it’s for the users own good’. It really isn’t, and I do sometimes wonder if your embedded Linux development team are competent or inept.

I think many will agree that Sonos users who have libraries that exceed the 65k track limit are very much in the minority. Couple that with the fact there are DLNA/UPnP and Plex Server workarounds to that limit, plus the fact that users are apparently turning to the online streaming music services, I don't see the point in this discussion, as the Sonos developers made the choice of how the local library indexing works years ago and it's not really what I would call a priority to revisit the way it works now, just to please the few.

I think most companies would shove this type of unnecessary development work to the bottom of their to-do list anyway.

I'm sure there are good reasons why the developers chose the route they did at the time and for the majority of people it works well with their local library and speakers, no point changing it now when there are probably far more pressing things coming down the line at Sonos.

Much better to keep the Sonos development train moving forward, rather than pausing here to take a nostalgic view of where their journey began in the now distant past.

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.

@Ken_Griffiths , what you are really saying is that the limit is irrelevant for most people, and that it's not worth Sonos' time to find a way around it. I suppose I must have been unclear because these are all points I made at the very beginning; like I said at the beginning, my question was just curiosity for its own sake, with no practical application, because I very well know that, regardless of the historical reasons for it, most people aren't affected by the limit and it's not going to change.

The point remains that it's a very poor and flawed design. If I remember correctly, and as said here, the first Sonos units were some kind of amp controlled by an ipod-like controller. The limit probably comes from how much memory they had fitted in this ipod-like thingy (the CR100).

It's not clear what the limit, in MBs, of the index file is. Other threads on the topic never obtained a clear answer. It seems somewhere between 5 and 50 MB. But, as far as I remember, even around 2004, when Sonos started, memory was not so expensive - in fact, it was probably hard to buy only 50 MBs!

When then Sonos expanded into speakers and started adding PCs and phones, then it should have thought that it would have made more sense to keep the index file on the controlling device rather than on the speakers.

Imagine if Microsoft had imposed a limit on the number of pages a Word file can be, or Adobe on how many photos a Lightroom collection can contain. Even if the vast majority of people weren't affected by these limits, they'd remain poor and flawed design; almost irrelevant from a commercial and marketing standpoint, but horribly flawed from a technical standpoint.

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.

Such as? Other than they didn't think it would be an issue.

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

Such as? What pitfalls?

[quote=amun]
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; when smartphones and PCs were added, it meant that they had to read the index which was stored on the speakers, so what are the speed advantages?

The 65K limit is of zero relevance to the very vast majority of Sonos users, especially as there are good workarounds for those who do have (very) large local libraries. So, this discussion is mostly navel-gazing, and has been done to death on many other threads.

The 65K limit is of zero relevance to the very vast majority of Sonos users, especially as there are good workarounds for those who do have (very) large local libraries.

Which is what I said at the very beginning and reiterated above, too, so why you are repeating it is, honestly, beyond me

So, this discussion is mostly navel-gazing, and has been done to death on many other threads.

I may have missed it among the many complaints about this limit, but I haven't seen many discussions on why it was done this way at the very beginning. Like I said and reiterated, mine is just curiosity for its own sake; if you don't see the point in this curiosity, why waste your time and mine with replies that add nothing to the discussion? Would it not have been a better use of everyone's time to just ignore this thread?