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.
On the 65k limit: why do speakers index music? It just seems incredibly poor design!
Bkb wrote:
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]
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.
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.
amunI 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.[/quote wrote:
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.
amun wrote:
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....
Bkb wrote:
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.
Bkb wrote:
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.
ratty wrote:
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.
YetAnotherLondonder wrote:
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?
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?
YetAnotherLondonder wrote:
Yes.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?
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.
ratty wrote:
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.
YetAnotherLondonder wrote:
No idea, but that's a fundamental part of the design. (I only use 5 shares at present.)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.
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.
jgatie wrote:
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.
Bkb wrote:
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.
It has nothing to do with speed - that is a lie. It is bad software, plain and simple.
Bkb wrote:
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.
jgatie wrote:
This thread isn't even about SMB, it's about the track limit. Please try to stay on topic.
Bkb wrote:
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.
Userlevel 7
+25
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.
Ryan S wrote:
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...
YetAnotherLondonder wrote:
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...
Userlevel 7
+20
The SMB 1.0 issue keeps getting less and less important, when you can implement an SMB 1.0 gateway to any network file system for under $50 and 20 minutes using a Raspberry Pi 3A+. It just isn't worth the massive effort and possible functionality loss to upgrade Sonos to SMB 2 for the few folks it would impact.
Same with thew 65K limit, so may work-arounds are available that Sonos just doesn't see the need to change it. And as said above the number of folks needing it is continually dropping.
Plenty of other issues impact more folks, and cause more unhappiness that Sonos is going to make priorities. I see no reasonable hope that these two are ever going away unless they get tacked onto a massive firmware revision that Sonos does for another reason.
Same with thew 65K limit, so may work-arounds are available that Sonos just doesn't see the need to change it. And as said above the number of folks needing it is continually dropping.
Plenty of other issues impact more folks, and cause more unhappiness that Sonos is going to make priorities. I see no reasonable hope that these two are ever going away unless they get tacked onto a massive firmware revision that Sonos does for another reason.
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
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
MusicMouse wrote:
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. [...]
That is already the case. The controller app is purely a remote control, all data ('My Sonos', settings, playlists, favorite radio stations etc.) is stored on the speakers.
MusicMouse wrote:
Hey, another idea - open source the non-proprietary code for the app. This would allow the community to contribute rather than just complain...
Right, and become another Squeezebox "success story".
You do know they have an API that the "community" can and does use, right?
chicks wrote:
Right, and become another Squeezebox "success story".
Squeezebox came and went before I got a chance to try it (which supports your point I guess.) That said, I am fairly certain that an architectural change that would be transparent to 99% of users, outside of the performance benefits and upside of potentially richer metadata would not change Sonos so much as enhance it, imo.
You do know they have an API that the "community" can and does use, right?
MusicMouse wrote:
Hey, another idea - open source the non-proprietary code for the app. This would allow the community to contribute rather than just complain...
Right, and become another Squeezebox "success story".
Squeezebox came and went before I got a chance to try it (which supports your point I guess.) That said, I am fairly certain that an architectural change that would be transparent to 99% of users, outside of the performance benefits and upside of potentially richer metadata would not change Sonos so much as enhance it, imo.
You do know they have an API that the "community" can and does use, right?
I was not aware. Thanks for raising. I did a quick search for 3rd party android apps a couple fo days ago and came up dry. Are you aware of any poweamp type players that work with sonos?
Thanks
MusicMouse wrote:
I was not aware. Thanks for raising. I did a quick search for 3rd party android apps a couple fo days ago and came up dry. Are you aware of any poweamp type players that work with sonos?
Thanks
There are several open source projects on github. HiFi Cast is probably the best Android app that uses the Sonos API (or UPnP, not 100% certain). BubbleUPnP is another. Nearly all of the streaming vendor apps will play to Sonos via one method or another - Sonos Direct Control, Spotify Connect, Alexa Cast or Google's oddball method from GPM. ALL of them will play to Sonos via AirPlay 2 on iOS devices. For iOS, there's also SonoPad and SonoPhone, which are decent.
Keep in mind that these will normally not work with files on a phone, they must be on a NAS or other media server like ShoutCast or IceCast.
HiFi Cast:
Top liked
What's going on?
- 109,234
- Topics
- 559,579
- Replies
- 265,212
- Members
