Sonos can't process large library, even if it is well below the 65,000 track limit... unless split into separate folders

As has been explained in may other threads, the track limit is not a specific number, but a combination of the data in all of the fields that are stored as part of the metadata for each track. And there’s a limit to the amount of memory on each Sonos device that can be dedicated to the size of that. Of course, Sonos restricts that to the devices that could be in your system with the smallest amount of RAM, and doesn’t allow it to be a variable amount of data, since by definition, the library needs to be stored on each and every Sonos device in your system. 

If you have large amounts of metadata, such as lots of artists, or lyrics, or even large names of files (symphonies are a common thing here), it all impacts the amount of data that can be stored. So you should consider that 65K number to be rather fungible, depending on lots of other factors.

I’d think, speaking personally, if it were an “easy fix”, Sonos would have done so long, long ago, as this has come up time and time again in these forums. 

Very much so - I’ve hit the limit at about 38k tracks.

I move less used tracks out of the library to make way for new ones. Casting the music to a CCA via a NAS media server allows access to all of the tracks, if I have to use them.

I think that’s one of the reasons that Sonos partnered with Plex, in order to get around that memory limit. You may want to look at that as a potential solution. 

For some of the library functions I think that there is a processing time limit. By splitting the library into smaller shares you may be reducing the running time for each segment.

Examine the length of your file names. Some rippers will attempt throw the whole first stanza of an opera track into the file name. While the system would be fine with a single folder and file names of 1.flac -- 65000.flac and these would be easy to process, the human would have some trouble with this organization. I try to keep the folder and file names broad and short. I’ll have major folders, such as “Christmas”, “Halloween”, “kids”, that allow including and excluding categories for special occasions, then Artist, CD and finally “TRK01.flac … TRK99.flac. 01.flac … 99.flac would be just as valid. This is a decent compromise that allows me to easily find a file when necessary.

The library can be split into up to 16 shares. A Christmas share can easily be included or not.

Up to some operating system limits, SONOS does not care about file size. Another technique to minimize the number of files would be to lash the tracks of large works, such as an opera, into a single track. Many people would never listen to a partial opera.

I think you are missing the point. Yes, I know the track limit is not a fixed number, I’ve read the many other threads that explain that.  But, whether my library is in one folder or two folders, the total data and metadata of all tracks is exactly the same. i.e. I am clearly not hitting a limit on the amount of memory needed to store the metadata or other data. Because it is the same either way. i.e. Once processed it is the SAME library, with the same songs, the same metadata, etc..  It is just processed in two chunks if it is split into two folders. 

As for “Sonos would have done so long, long ago...” I haven’t read any threads where the problem was resolved by splitting it into two folders, so I don’t think your point is applicable.

Also FYI, I am a software developer myself and have some insight into these things. If I can resolve the problem by splitting my library into two folders, which results in the Sonos software running the indexing process two times (i.e. once for each folder) but writing the results into a single index (to be stored in memory) then it is almost certainly an easy fix.

Except that I am clearly not hitting a memory limit, as the entire library does fit into memory. The problem is not the size of the library (as evidenced by the fact that the library works fine if I split it into two folders.)

File names are not unreasonably long, and the number of tracks is clearly not the problem as it is able to handle the whole library if I split it into two folders.

The running time theory might be it though, although I can’t imagine why Sonos would cap the running time and simply give up after some period of time.

I have not read the whole thread, so I may have missed something - but per the quoted are you saying that with this, your use case is fully addressed?

Implied as part of the indexing process is a hash or sorting scheme. These are surprisingly complex processes that have exponential time penalties if the input data is accidentally in the wrong order. One of the simplest sort schemes is blazingly fast if the data is accidentally in the correct order, but is one of the worst possible choices if the data is accidentally in reverse order.

I think that a fundamental SONOS design philosophy is not to allow a system to be trapped in an endless loop of some sort. The most graceful bailout from an apparent endless loop is a time limit. At least there is some sort of error message indicating that the situation is somewhat under control. In the case of our library index, it is possible that, if the process was allowed to run for a few more hours, it could complete normally. I think that each share is treated as an independent block of files, resulting in a smaller time exponent for each of the smaller, more or less independent blocks.

Sonos staff can see data you can’t on your Sonos, it might be worth calling and starting a series of tests with them to see if the diagnostics you can submit or their other tools can show them anything that they can share with you.