Music Library on router USB drive

No documentation here, just my poor memory of past discussions.

Indexing is done on the speaker you are connected to, unless the Sonos software feels it is underpowered or too low memory to do the index well, then the software steps in and assigns the index to a better speaker iv available.

I don't think there is a way for the user to be sure where the index is generated. The reason I suggested powering down all but the most capable speaker. Get it done and then let it propagate once the others are on-line.

Again no way to actually tell on the sharing once the index is generated but based on my Linux knowledge I'd lean to expecting "rsync" to be doing it. Very powerful file sync tool with a lot of optimizations to reduce cpu and memory load and minimize bytes pushed across the network.

My NAS is mounted read-only so no possibility of Sonos doing anything there.

Certainly my understanding was that Sonos had no ‘write’ privileges beyond its own domain. I’ve always taken the assumption that playlists were stored in the RAM of the speakers…one of the various things that get erased when someone does a factory reset. And in this case, playlists are essentially the same thing as NAS data…or any Sonos stored pointers to existing data, whether it is NAS located, or otherwise. If the data was written to the NAS in some way, then the reset would be able to re-load that data. 

But I’m neither a programmer, nor do I have access to Sonos’ code base, so these are assumptions. 

I think you are right, anything that survives a power-cycle is in internal persistent memory.

The factory reset wipes the user and system data portions of that memory while not touching the operating code portion.

I can’t debate the issue either. I’m possibly wrong about where the indexing takes place. However, I can’t find or fathom any logical reason why a single speaker would be responsible. That premise suggests that if I removed the speaker for whatever reason my library would be broken and you know that l’ll upgrade a speaker in a New York minute 😂.

Heh. No, because (IMHO) the ‘list’ is copied from the originating speaker to existing data on all other speakers…so no single speaker holds the only data about the system. The same, I think, applies to the rest of the information, so it never exists on a single place, and that the loss of any device, including a controller, has no affect on the ‘system’. All Sonos devices share everything…which is one reason there’s so much crosstalk (although not the only reason).

So there is one ‘device’ that does the scan, but once it’s complete, the data is distributed to all. 

Again, just my guess as to how Sonos works. All the caveats apply, as before ;)

​@Airgetlam (or anyone) 

OK…riddle me this Batman 😊

Jokes aside…How do I determine the target speaker for indexing🤔

I don’t think you can. I think it’s the first speaker in the ‘list’ maintained by your Sonos system. I don’t think there’s any control by the user, despite several posts from people claiming they’ve done so. 
 

I suppose you could unplug all but the desired device, then manually run the scan, then plug back in all the rest of your system so that the data gets copied over, but I don’t think there’s any way to ‘define’ which device is used. I don’t even think there’s any way software looks for the ‘fastest CPU’, or the ‘most available RAM’ to use….but I’m just hazarding a guess. 

Probably, based on Sonos policy (like Apple) if the connected speaker is an old one, the connection with the nas is lost and the indexing is not working anymore. This could be the reason why keeping on trying, after dozen of tentatives it works. It’s only a thought but don’t forget tons of problems app faced during the last 2/3 years, so would not be surprised if this is a “new” app issue due to the fantastic development of the last 20 versions….

The target speaker for indexing is the associated product. In the pre-May 24 phone/tablet apps, the ‘About your system’ used to show this but no longer does. The Mac/Windows apps being of a certain vintage still do. With all the testing I have done in the last few weeks, the associated product and the behaviour of indexing correlates exactly. The Era 300 is almost guaranteed to become the associated product for me as it boots so much quicker than anything else. So post firmware updates (quite regular) it will assume that role until I power cycle it, leaving about 5 mins between off and on so the other speakers elect a new ‘associated product’. The first speaker to power on will become the AP until it power cycles. 

As pointed out above, Sonos can’t store the index on a NAS as (Era 300 aside) the index takes places even if the music is on a read-only share. Also if you are able to to track NAS write activity during an index you’ll see there is none. 

The index is propagated to all speakers which is why there’s a limit on no. of tracks as it has to be able to reside on all speakers. I don’t know what the memory limit is, and if you have lots of devices with more memory I don’t know if the system allows it to be bigger. (Would be nice for some I’m sure) Sonos don’t seem that bothered with enhancing the local library experience. 

The controllers use the basic index from a speaker (with varying degrees of success on search) to display metadata and they then (mostly) access the NAS directly for stuff like album art to make it all look pretty, as it would make no sense to store that on the speakers given the picture info is quite large relative to index info. 

This is a different approach to something like Minimserver which if installed on a NAS creates its own space where it does hold its index. However, it’s a server based product that distributes data in a different way. 

No, your library is not broken because each speaker has its own copy (for resilience and speed) and if the elected AP disappears, the system elects a new one from the remaining speakers. So everything continues to function. It would make no sense in a larger system for each individual speaker (at the same time when requested) to all try and generate the same index from the same source. Much more efficient and stable to have just the one source and propagate it to the others when done. That also removes the nightmare of different speakers getting different results (happening now) and then the controller software would appear to randomly show different things depending on which speaker it connects to. At least when it’s wrong, it’s the same wrong system wide as it stands.

It also means when you add a new speaker, it just receives a copy of the current index from other speakers. Again I know this is how it works as if it didn’t, when I added my Era 300, it would have failed to index due to various issues. Instead it received the library index but was unable to play any file as because it was built on another speaker, which was happy with SMB names where the Era 300 is not.

Finally, if each speaker didn’t have its own copy of the index, (we know its not NAS based as it can function with a read only music share) the system would not continue to function as you turned off each speaker. It does. And you if you power all speakers off, you can choose *any* speaker to power on, and that speaker will be fully functional without needing to run a re-index. That can only happen if each speaker has its own copy. If you don’t believe that, then keep the desktop controller running, and as soon as it detects the speaker, open the Manage Music Library Settings menu, and if a re-index is taking place it will tell you there. It won’t be. (and it takes much longer to re-index than it will take the controller app to see the speaker and for you to open the menu…)