Indexing Music Library

As a guess, it may have to do with the CPU doing the processing, in conjunction with available RAM, where it may be doing swapping. Scanning data is certainly a different operation than a backup. 

How many of the internal tags does your backup process?

How many indexes does it generate so you can search your music based on them?

How many cores, how much speed, how much memory in your backup device versus your Sonos?

Might go faster if you did the indexing from your most capable Sonos device. 

Does Sonos choose the “Associated Product” ( The product that takes the index ) by looking for the most qualified product to execute that function?

Been a long time since I saw the Sonos position on this.

Originally it was the associated device, then I think it was tweaked so that if the associated device was underpowered it would move the indexing to a  more powerful device. I don't recall any details on when the switch was done. Also haven't seen anything recently so it may not be in the new app.

Edit, also don't know how you'd tell where it was being done, maybe feel for the warmest one? :-)

How large is your library? Where is it stored? Are your players wired or wireless?

Probably there is some network congestion. Each track must be fetched from storage by the player running the index and processed by the player. Eventually a copy of the index will be sent to each player. A first build of a new index takes longer, adding or updating a few tracks is much faster.

S2 takes 10x as long to scan my library as S1. Same library. I’m not sure why that is the case.

I’ve not attempted to put a number on it, but I’ve noticed that the S2 indexer is slow.

One has to wonder if both are using SMB to access the data. I could see there being different access methods…and different code methods. 

All use SMB, but S1 uses the v1 and S2 uses v2. It’s been a very long time since I worked on the SMB stack (on the Xbox 360!) so I can’t recall if there is much of a performance difference at the file system level.

Might be as simple as the original Sonos coder carefully crafted the sort to use the available hardware and maximize performance. Then the S2 coder came along and when they needed a sort just linked in a generic sort library since the new hardware can support that.

Been a long time since I did embedded (what Sonos firmware code is) coding but the transition from the protype that used generic code in a high level language, on a big system, to get the concept and flow right, to the scrap all but the logic, and hand code in assembly, from scratch, to fit the embedded hardware was amazingly fun. Twiddling individual bits, managing  memory at the byte level and counting every CPU cycle, geek heaven. Most of the coding was done on paper, with a pencil, maybe 20 instructions per sheet of paper.

Well, I’m still of the opinion that scanning data for individual tags and storing them in a list is a larger task than just copying a file (dependent on the memory where the data is written). One is looking at multiple data points for each file, and storing it, the other is a low level command execution of the entire file. 

I have a 1.9tb library of uncompressed .flac files in a single share with 55/60k tracks. An S2 index request, usually on an associated Play 5, for an:

• Album addition - a few (+/-) miniutes
• Sub level folder rename (+/-) 20 miniutes
• Top level (ie. a share name change) maybe (+/-) 30-50 miniutes (ish 🤔)

I may be a little vague and suffering from a slightly optomistic memory, but I would expect a total share name change to be done in the time it takes to have a P, make and eat a sandwich, check social media, maybe make a call or two and pick my nose for a while 😋

(for comparison, a full backup to a USBc connected drive can take a LOT of hours...)

For comparison on a similarly sized library… On my previous NAS, S1 took 5 minutes for an update and S2 took 55 minutes. I just set up a new NAS and now S1 takes 1.5 minutes and S2 takes 15 minutes.

What kind of drive, and connected how? Gen 1 or 2 Play 5?

My library is on an SSD, Raspberry Pi host, and 100mbps Ethernet. A lot smaller, all FLAC, and seemed quick when last tried.

I may fool with it, try my Arc Ultra and then a Play 3 and compare speeds.

Can you change your Associated Product or are you unplugging to force the index to be done on the only powered Sonos Room.

Access to the music library is read only. There’s no need to worry about drive write times.

​@Stanley_4 

Synology NAS running HDD in a RAID configuration. Dual 1000mbps ethernet bond with Sonos on 2.4/5Ghz auto selected Wi-Fi (via 1000mbps ethernet) using a NAS user with read/write access (which now seems to be a requirement)...

Oh, not Play:5 but Sonos Five as associated speaker 🙄

Not sure what mbps the Wi-Fi network runs at but have never noticed any issues and it reports well…

(and full backup to a similar spec networked NAS via Wi-Fi takes some hours too...)

Wow!  I have 46,000 tracks.  Index takes around 10 minutes.  Of course that’s an index looking for new music I just added.

My new NAS is a Synology DS225+. The sonos NAS user has read only access here.

But read times, particularly on a low memory and slow RPM Green drive, can be an issue and a SSD is usually faster for that, even with a speedy hard disk or NAS.

I have found that, since a Sonos update towards the end of 2025 (ish) that if adding or changing the name of an existing indexed share, the Sonos user requires full read/write access. Without it Sonos allows adding/changing name of the share but the indexing fails. Existing indexed shares remained OK and re-indexable 🤔

I have not checked this very recently but will do soon as I am about to reorganise my library...

That’s interesting. I set this up as new share, new name with the sonos user read only right from the start. Sonos added it and indexed without a problem.