Exceed the limitation of the number of managed files (65000 units)

If you submit a diagnostic and contact Sonos Support they can look at the storage numbers and let you know where you are.

If you are close to the meta data limit but not the track count limit, you might be able to fiddle your music collection setup to lower the space it is using. I have never been close to the limit so I haven’t bothered to fool with that.

Wow, thank you for the speed and precision of your feedback, it's really very appreciable... ;-)

My music folder is made up of just over 64500 .mp3 audio files: it would be really “handy” to be able to consult this number IN the SONOS application itself, wouldn't it?… (baffling that SONOS tech support can apparently give out the index count of my install, I feel a little watched!...)

What happens when we exceed this threshold of 65,000 units?…

Is the FIFO rule applied?…

The SONOS application warns us with a message?…

Or files taken at random fall into a black hole?... ;-)

Otherwise, my .mp3 files are fully and totally tagged and each of them has a cover of about 60 kb.

NB: I never really understood why adding a simple and audio album (containing about ten tracks) causes the SONOS application to take such a long time to process indexing?... .

Thanks again for your attention...

A diagnostic is voluntary, you choose to do it via the app.  So, the only way Sonos can “watch” your index count is if you send it to them.  

As the library is scanned, SONOS simply asks for a list of files and processes these files until exhausted or a limit is hit. I haven’t noticed any messages when a limit is reached, SONOS has no control over the order of the list, but it probably only works with one share at a time, This lack of order control can cause pain for the human because successive runs that hit a limit could result in a slightly different list of included files near the end of the run.

Run times vary because file modification time of every file is checked. If a file has not been modified since the last index run, the file will not be processed. The first run will require more time because all files must be fully processed. Updating a file or adding a few new files is much faster.

Runs can also terminate early if there is an issue, such as a corrupt file.

Near duplicate metadata can also cause pain because duplicate tracks are skipped. This can result in complaints that “I updated the composer, but the library index does not show this”. Also, you should disable your NAS’s recycle bin because this will be scanned and can result in the old file in the recycle bin being discovered prior to the newly edited file.

On a desktop controller you can go to Help → Error Log… . Sometimes something useful will show here.

Great, thanks again for your help...

I’ve seen reports of “ignoring my edits” caused by library managers that do not update the file’s timestamp. This will cause the SONOS indexer to skip that file.

There used to be a facility to check the info yourself, but Sonos removed it a few years ago.

Sonos is in a bit of a corner, protect the clueless or give the power users more info.

Maybe at some point the S2 systems can offer password protected access to the internal data while still protecting folks with open WiFi or enabling port forwarding on their routers.

I really miss the data access, far more fun to troubleshoot myself than post diagnostic codes and wait/hope for a response.

The info is there,  just show it in the App somewhere (About My System).   No need for fancy webpages etc that were deemed a security risk.

In the app would be handy, but putting it at the Sonos :1400 web server might be less confusing for most Sonos users that don’t use the Music Library functions.

Some of the removed info didn’t have any security impacts that I could see.

Hello, I just added some mp3 files to my database and restarted the indexing. And I got this message pretty quickly:

“Insufficient space to update your music library. Delete unused playlists or saved playlists and try again.”

“Espace insuffisant pour mettre à jour votre bibliothèque musicale. Supprimez les listes non utilisées ou les listes de lecture enregistrées et réessayez.”

So I deleted all the Reading Lists, i.e. the 125 lists that I no longer used. I restarted the indexing and, again, I got the same message of refusal!... I then directly deleted mp3 files from my music database on my NAS: I had 64724 mp3 files and after deletion, I am now at 64000 mp3 files. And the indexing was able to take place.

Otherwise, I find it quite... particular that the macOS application is much poorer in functions and that some of them are only accessible on tablet or mobile!... Why these limitations?...

Finally, if you want to delete Reading Lists, you have to do it one by one: we think we're dreaming!... So I deleted more than 100 of them and it took too long minutes of manipulation! ...

The phone/pad controllers are full function, desktop controllers are limited function. For day to day system operation I prefer to use a desktop controller, but I must use a phone/pad controller for configuring the system.

The hard limit is 65,000 tracks. In addition, there is a space limit for the library index and playlists. You are hitting the space limit. Shorter file names would be the easiest solution. For example, I’ve noticed that some rippers will include the words of the first stanza of an opera in the file name. In my opinion this is excessive because “01.FLAC” would be sufficient in most cases. While not ideal for the human, all of your tracks could be piled into a single folder and named “1.FLAC” … “65000.FLAC”.

There is no limit to track file size.