I understand there is a limit of 65k tracks, or fewer, depending on metadata. I understand Sonos is extremely unlikely to ever overcome this, that the users who are annoyed by this are a small minority, etc.
My question is just curiosity (with little practical implication as the limit is unlikely to change): why? I understand the limit has to do with speakers indexing the music collection, but why on Earth do speakers need to index my music? Shouldn't that index reside only on the devices which control the music being played (computer, phone, tablet), rather than on the speakers, too? I see many downsides in storing a copy on the speakers, this limit being one, but I can't see many upsides. Indeed, AFAIK Sonos' competitors do not use this system and do not have this limit.
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.
Page 1 / 2
No. The controller is just a remote. Your TV stores the channels it gets, not the remote control. Same with Sonos. So any controller that joins your Sonos has access to all of the streaming connections that have been set up. The only thing the “other” controller doesn’t have access to is music “on this device”.
There is effectively no data stored in the controller. Which keeps it small in size, especially on devices that have limited memory, such as phones. And remember, this system was designed in the early 2000s (company founded in 2002), and is probably some of the backbone code that runs the Sonos ecosystem. Things have changed since then, but it might be challenging to switch out the skeleton while keeping the patient alive.
There is effectively no data stored in the controller. Which keeps it small in size, especially on devices that have limited memory, such as phones. And remember, this system was designed in the early 2000s (company founded in 2002), and is probably some of the backbone code that runs the Sonos ecosystem. Things have changed since then, but it might be challenging to switch out the skeleton while keeping the patient alive.
Sonos was designed to keep playing regardless of the presence of the controller. Each player is able to access the music even if the controller that initiated the queue is turned off, leaves the home, is dropped in a fish tank, etc. That's why all service info, the index, playlists, the queue, etc. are stored on the Sonos hardware, not the controller device.
Also, at last count a few years ago, 92% of streaming was internet based. The man hours spent recoding to put the index on multiple mobile devices that come and go on a whim for a niche subset (local libraries over 65,000 tracks) of an already dwindling number of local library users is probably not going to see much of a ROI.
Also, at last count a few years ago, 92% of streaming was internet based. The man hours spent recoding to put the index on multiple mobile devices that come and go on a whim for a niche subset (local libraries over 65,000 tracks) of an already dwindling number of local library users is probably not going to see much of a ROI.
So, when I open the Sonos Android app to play, I don't know, Adele's Hello which is on my NAS, what the app is really doing is telling the speakers: this song corresponds to the unique id 123 in your library, go and play song 123, and the speakers will automatically connect to song 123 on my NAS?
This answers "how", but doesn't answer "why": what are the advantages of this kind of set up?
The speakers do not have and do not need to store an index for online streaming content (Spotify, Tidal, etc) - why do they need it for local files?
You mention limited memory; back when Sonos was founded, smartphones as we know them now didn't exist. Was Sonos controlled from PCs? How much memory was really needed to store 65k songs and how much did this memory cost back then?
Again, it's just a curiosity with no practical implications, but to my non-technical, non-developer eyes, it just seems like extremely poor design
This answers "how", but doesn't answer "why": what are the advantages of this kind of set up?
The speakers do not have and do not need to store an index for online streaming content (Spotify, Tidal, etc) - why do they need it for local files?
You mention limited memory; back when Sonos was founded, smartphones as we know them now didn't exist. Was Sonos controlled from PCs? How much memory was really needed to store 65k songs and how much did this memory cost back then?
Again, it's just a curiosity with no practical implications, but to my non-technical, non-developer eyes, it just seems like extremely poor design
Thank you, I know that, but that was not my question. The question was not: why does Sonos not change this? I said in my post that I fully appreciate Sonos is extremely unlikely to ever lift this limit. The question was: why did they come up with this system in the first place? And, just to be super clear, I did state it is just curiosity with no practical implications, because, regardless of whether there were some intrinsic reasons I fail to grasp, or whether it was just poor design, I fully get it's not going to change.
This answers "how", but doesn't answer "why": what are the advantages of this kind of set up?
The speakers do not have and do not need to store an index for online streaming content (Spotify, Tidal, etc) - why do they need it for local files?
No, it is telling Sonos to put song 123 in a queue. Then it may tell it to put song 244 in the queue. Then another device may tell it to put song 64 in a queue. Then the first device might be turned off and the second leaves the building. How is Sonos supposed to know what songs to play without access to the index?
Online content uses a server to serve up tracks to the clients. Would you want to keep a PC running a server or set up a server on an NAS ala Squeezebox to get what you wish? If so, Plex is supported by Sonos, with all the limitations of that type of setup.
Again, it's just a curiosity with no practical implications, but to my non-technical, non-developer eyes, it just seems like extremely poor design
It is actually a great design, with the limitation of not being optimum for the small subset of users who have over 65K of tracks.
Userlevel 7
+26
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.
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.
No, it is telling Sonos to put song 123 in a queue. Then it may tell it to put song 244 in the queue. Then another device may tell it to put song 64 in a queue. Then the first device might be turned off and the second leaves the building. How is Sonos supposed to know what songs to play without access to the index?
So the advantage is that I can set a playlist on my phone, then switch off the phone and Sonos would continue to play? Or that I can add a song to the playlist, my wife another one, then I another one etc?
Is there any advantage other than these, which are totally irrelevant for me (but might be relevant for other people, who knows)?
Would these advantages apply when streaming online content, too? I'd think not, but maybe I misunderstood how Sonos works? For example, if I create a Spotify or Tidal playlist on my phone, will the phone somehow send the playlist to the speakers, or do the speakers need the phone to tell them what to play next?
Online content uses a server to serve up tracks to the clients. Would you want to keep a PC running a server or set up a server on an NAS ala Squeezebox to get what you wish? If so, Plex is supported by Sonos, with all the limitations of that type of setup.
Plex is not an option because it is almost impossible to import existing playlists. I believe many people living in properties bigger than a 2-bedroom apartment and with large music collections have some kind of music server, whether it's a NAS or an always-on PC (which effectively acts as a server). If you have 60k songs, you're unlikely to have all of them on your phone. I have Roon running on a NAS, which I understand works with Sonos even though Sonos doesn't officially support it. But we're going off-topic!
So let's see if I get this right:
Let's say I am setting up Sonos for the first time. I open the Sonos app on my Android, direct it to look for my music somewhere (a NAS, a PC, my phone, it shouldn't really matter) , then what happens?
The Sonos app scans the folder and subfolders, creates an index of the files it finds, and sends it to all the Sonos speakers in my house?
Then the next time I open the Sonos app, the app will read the index from the speakers?
Or does the Sonos app store a copy of the index, too? It would be very slow and inefficient to fetch it from the speakers every time.
What devices were used to control Sonos back when it was designed around 2003 - 2005? Only PCs and Macs? Nokia phones?
Userlevel 7
+26
Let's say I am setting up Sonos for the first time. I open the Sonos app on my Android, direct it to look for my music somewhere (a NAS, a PC, my phone, it shouldn't really matter) , then what happens?
The Sonos app sends a message to your indexing player, ideally the one that it has the best connection with, and then the player contacts that network location, scans the location for all files that are readable, and builds the music index. Then, the index is distributed to all of your Sonos players.
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.
The first controllers were the Sonos CR100, our own device built for the purpose. Then computers were added, a new version of a Sonos Controller, and finally apps for smartphones, first iOS, then Android. And with each one of these, the music index remained stored and accessed in almost exactly the same way. Though we did manage to make the index larger a time or two.
It’s very simple to work around the 65K limit. Just use an app like Hi-Fi Cast, which can interact with the music server on your NAS (Twonky, etc), and with your Sonos speakers. Works great, no 65K limit.
@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.
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.
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.
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.
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?
Userlevel 7
+20
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.
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?
Userlevel 7
+20
Done.
Userlevel 7
+21
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 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. 🙂
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.
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.
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.
Page 1 / 2
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.