My music library is located on a NAS (Synology) - it recently stopped updating the entire library. I’ve deleted the path and relinked it multiple times and it still updates the same incomplete list of files — there doesn’t seem to be any rhyme or reason to what it indexes and what it doesn’t, for instance there are some bands that I have on compilations and on albums, and their tracks from the compilations come through just fine but their albums don’t, even though the metadata is very similar. If I add new files they will sometimes show up in the index, sometimes not. I have about 40K tracks, so much lower than the 65K limit, and most of them are not recorded at unusually high bitrates. Does anyone have any suggestions?
Page 1 / 1
Submit a diagnostic after trying an index, call the Sonos folks with the ID number so they can take a look.
The limit is more complex than just 65K and you may be hitting one of the other limits.
I’d agree with
I have about 39k tracks in my library as Sonos won’t take any more, but many are classical - which tend to take up more store.
Thanks to both of you, will do! I get the impression that Sonos isn’t very concerned about supporting libraries anymore now that we’re all supposed to pay for monthly streaming services but I like having my files, especially because there’s a fair amount of music you can’t even find streaming.
Search here for Plex which is a good solution for large libraries.
The 65K tracks and other limits are legacies of the older Sonos gear with very limited memory, there is always hope that the S2 software will alter that limits at some point. The driver for that happening is likely the number of customers that hit the limits and complain.
Just looked at my library, most was bulk added in 2007. I added 2 albums in 11, 1 in 17, 2 in 18, and 1 in 19, nothing since, so I’m likely not going to hit the limit before I’m in a nursing home.
The track file names might be the issue. Some CD rippers create very long file names when they could be only 0.flac to 64999.flac. If long file names take up too much storage, you’ll fall short of the 65,000 track limit. I store each album in a separate folder. For lack of imagination, the track names start with Track01.flac in each folder. This scheme requires very little space and is somewhat human friendly. I can easily find each track if I need it. There are music library management programs that can change all of your file names in a batch process.
If you use a batch process be sure to have a backup in case the batch process gets out of control.
The bitrate is irrelevant as Sonos does not store the files, but the filepaths.
As others have said, it is possible that you are hitting the track limit due to some filepaths taking up two ‘slots’ in the available space. But there are other possible explanations, for example:
- Incorrect metadata. It is worth checking the ‘Folders’ view in the Sonos Music Library. Are any of the tracks missing from the ‘Artists’ view to be found here?
- Unreadable characters in a particular file causing the process to abort
- Latency in the system, caused (for example) by interference. Which Sonos devices do you have and how do they connect to the LAN?
Incidentally, there is a setting for how compilation albums are handled, and I believe there is a metadata flag for compilations. But I have few such albums and so I have never looked into this closely
Update: I just reindexed to try and get diagnostics and all the missing albums are there, mysteriously. On subsequent indexings they may disappear again, as I’ve seen before. However, it does seem like moving to Plex is a better long term solution. Thanks everyone for their thoughts and advice!
SONOS can be impatient. If network congestion slows the process, the indexer will terminate early. The congestion can be variable. For example, one player will take charge of the indexing process and update the other players at the end. If this player is congested the process might terminate, however, if the next attempt uses a player with a better connection, the process might be successful. I have no proof, but I suspect that when the indexer is a newer, faster player there is less chance of a timeout.
A work around to improve your chances of success is to break your library into separate shares, such as “Jazz”, “Classical”, etc. The indexer will fully process one share before moving to the next share. This reduces complexity for the indexer and it can work through each share faster -- reducing the chances of a timeout.
Excellent insight, thanks!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.