Meant to post this in Community.

Large metadata causes overflow in the space allocated for indexing. The indexer attempts to load the whole share’s metadata into the space. This is why breaking the library into smaller shares is more likely to be successful. Another issue with long metadata is that each track has a ‘slot’ allocated for metadata. If the metadata overflows the slot, a second slot is opened. With excessive metadata, the library can easily max out in the 30K range.

Just breaking the library into smaller shares didn’t work, as the total amount of metadata still exceeded whatever Sonos’ limits are.

It’s a significant issue that Sonos does not clearly set out the limitations on metadata capacity and slot limits so that users can be aware of them. Precise error messages would be nice, too.

Notably, as my library was unchanged before and after the May update, something appears to be different with regards to how much metadata Sonos generates when indexing the exact same library, i.e. the same library information is consuming more space.

I can imagine one other little bit of mayhem. Check the About… and make note of the Associated Player. This unit will run the indexing routine. If you have an older player with less RAM and this unit is the Associated Player, indexing might fail yet the indexing might be successful using another player with more RAM. As the controller starts, the first player to respond to a general query will Associate.

Both units in my S2 system are Rays, so should be comparatively well-off RAM-wise.

I also have an S1 system (pre-emptively downgraded when the May update was announced) that includes a couple of Play1 and Play3’s, and that system has never had an issue in all the time I’ve owned it, even as the library has grown over the years.

Hello...I am having this same issue since the July 22nd release.  After Sonos broke things with their new app I was eventually able to use the NAS workaround to access my music and playlists.  However, since the July 22nd release, I can use the NAS workaround to access my Music Library (indexing starts)...but after 5-10 minutes indexing stops with the error “<PathName> is no longer available.  The device where the music files are stored may not be powered on, or the path may have changed.”

I have about 36,000 items (almost all songs) in my local Apple Music library.  i don’t think I can set up 2 Apple Music libraries (like Superunknown) because I don’t think Apple Music can access 2 libraries at once.  I would then only have access to some of my music, depending on which Library I choose when I opened Apple Music (using the Option key).  (At least that is what I think)

I have added a a minimal number of songs between the June Sonos release and the July Sonos update (less than 100)...so I don’t think I crossed some threshold...something must have changed in how Sonos handles metadata between the June Release and the July Release that broke things.

Does it make a difference where the iTunes library is stored?  I have all my music in a shared folder called Music (Hard Drive\ It has 2 sub-directories...iTunes and Music.  iTunes has the iTunes Music Library.xml file.  Music has a sub-directory called iTunes...which has a sub-directory called iTunes Music with all my music files.  Don’t ask me why it is set up like this...i think it is an historical thing from the days before iTunes became Apple Music...all I know is that is used to work with Sonos  

Someone told me to bite the bullet and upload all of my local music into Apple Music and that this will solve my problems.  Other than the fact that I hate having to subscribe to another service just to fix something that Sonos broke, are there any issues with this solution?  I have a lot of music on my MacBook hard drive that I didn’t get from Apple Music...old CDs that I ripped (some of which are not on Apple Music), music found and downloaded from the internet, etc etc...does this music load into my Apple Music account as well and will I be able to play my playlists that contain a mix of tunes that are available in Apple Music and others that come from my hard drive?

Any suggestions? 

thanks!

I am having this same issue.  After the Sonos App stopped working in May/June, I was eventually able to access my music (stored in iTunes/Apple Music on my MacBook) and my playlists, using the NAS workaround.  However after the July 22nd update the workaround stopped working for me.  I am able to access my library using the NAS workaround, but 5-10 minutes after indexing starts i get the error message: 

‘//MyComputer/Music’ is no longer available.  The device where the music files are stored may not be powered on, or the path may have changed.

My Music Library has about 35,000 songs so I am below the Sonos limit of 65K songs.

Does it matter where the iTunes library sits?  My Shared Folder Music that I point Sonos to has a subfolder iTunes...where the iTunes Music Library.xml file is located and another subfolder called Music.  This Music folder contains the Music Library File has a folder called iTunes ...and inside of this file sits all of my music.  I’m not sure why it is set up like this...I think it is from the days of iTunes...all I know is that it used to work before Sonos changed their app (and then again after the 1st update release) so I am hesitant to change anything.

This worked after the May/June softwareupdate...so Sonos changed something in the July 22nd update which broke this.

Any bright ideas?

It has been suggested to me that I could solve this issue by subscribing to Apple Music and syncing my local library.  Ignoring the fact that I don’t like the idea of having to subscribe to Apple Music just to fix something that Sonos apparently broke, I am hesitant to do this because I have a lot of music that i did not get from iTunes/Apple Music (my CD collection which I ripped, songs I found over the years on the internet, etc) and I am worried that not all of these songs will upload/play in Apple Music .  Does anyone have any experience with this?  Will syncing my local music library with Apple Music solve my Sonos issue?  Will I still be able to play my playlists that contain songs that I own but might not exist in Apple Music?

thanks

In a recent thread I described the issue I’d faced since “The Update” that prevented me from adding my music library, hosted on a Mac Mini, to an S2 system. I had file sharing configured per Sonos recommendations (even before the update), and although Sonos could connect to the share it would fail during the indexing process with this incredibly informative error message:

 

 

TL;DR: If you encounter the above error, it may be an issue with the cumulative volume of metadata in your music library, despite that not having been an issue before the May update. This certainly affects shares stored on MacOS using libraries managed with Apple Music, although I will note that I do not believe this represents an issue with Apple's products, as it's clearly linked to a data limit within Sonos. However, it’s one you’re more likely to encounter if your music management approach, like Apple Music, involves naming files with proper names, rather than a simple disc-track numbering system.

 

 

FYI, in another thread where I explain how to upgrade a legacy NAS to SMB2, I discovered the following, when I got the above error. The SMB client (i.e. Sonos) is running out of SMB ‘credits’ - clearly a bug in either the client or server.

This is the message in the smb.log file that led me to this conclusion:

“smb2_validate_message_id: client used more credits than granted, mid 132097, credits_granted 0, seqnum low/range: 132097/0”

According to the Samba documentation this should never happen, but lo and behold there it is. I did try to increase (x 2) the credits in the smb.conf file, but it had no effect, indicating a subtle bug somewhere.

And this is only an issue with indexing, it doesn’t affect playback. FYI

I have both Apple Music and iTunes Match.  While I’ve had iTunes Match for years, I’ve turned Apple Music on and off. Both services will upload music content to the cloud that is not in the Apple Music catalog, so you can listen to the music you ripped anywhere.

If you become an Apple Music subscriber and add that service to your Sonos account, you’ll be able to access all your music including your playlists and ripped content. That’s how I’m currently accessing the content and playlists in my Mac Music library since error 913 popped up and the NAS workaround failed.

Why is this issue surfacing now? Why did the NAS workaround work between May and (about) August without triggering the Sonos metadata limitation? Is this a bug specific to the latest the Mac Sonos controller version 16.3 build 80155014?

This is exactly what is happening to me too. I am not about to subscribe to Apple Music as a work around. Now various speakers in my system have been going off line just to add to the fun. So many different things are going wrong, I hardly know what to troubleshoot for. I am sick of wasting time on this just to hear my music. Sonos, please fix this! 

A few hours after I posted my gripe, I was finally able to re-add my library without any access denied or path not found errors, doing the exact same things I had been doing over and over again all along. The music library was blank for a day or so, but today when I went to look, it was all back and accessible on my iPhone and Mac.One thing I noticed while checking folder permissions for the millionth time was a permission group called SonosDMS I don’t recall ever seeing before. For awhile after than it changed nothing in the errors I was getting, but then it finally took. Now I hope Sonos doesn’t do something to mess it all up again. Now I have to find a new hobby ;-)

I don’t think this is a new bug. However, some users will encounter the issue if/when their stored music exceeds the metadata limitation imposed in the Sonos firmware^. At that point, even though the user has configured their library using the Network/NAS option, the devices will be unable to finish indexing.

Splitting the library in two, and setting up each library via the Network/NAS option sidesteps the problem. I have demonstrated that this wasn’t an issue with the metadata content, but simply a limit Sonos impose on how much metadata a single ‘library’ may contain. Splitting my library in two solved the issue. I renamed some audiobook tracks after this just to give myself some more headroom for future library growth.

Based on Ianp’s reply, the underlying cause *may* relate to a bug that causes Sonos to run out of SMB ‘credits’. Or that could just be what gets written to the logs when the devices stop indexing due to the Sonos-imposed library size restriction. 

^ Approx. 65,000 tracks, but *heavily* dependent upon the actual volume of metadata, including track/artist names.

Did you solve this?

My best guess is that your library metadata may have exceeded the Sonos limit between June and July. Remember that the ‘limit’ of 65k tracks is variable - it actually depends upon the volume of filepath and metadata stored in the index.

iTunes/Music has the habit of naming the individual tracks in the MacOS file system using the track name entered in the app.

So instead of your disk containing files names like this:

/albumX/track1.m4a

/albumX/track2.m4a

…

They are stored like this:

/12 Gracious Melodies/Vasoline.m4a

/12 Gracious Melodies/Interstate Love Song.m4a

...

As you can see, this will rapidly chew through the Sonos data allocation much faster than ‘basic’ naming. And this is before the actual metadata that Sonos reads from the files in order to show you the album/artist/track/genre information used in the app.

So, my recommendation would be to *copy* a subset of your music to a new location on the disk, create a new iTunes/Music library and add the music from the new location. Then setup the new library in Sonos. If that works, then you’ve demonstrated that the problem is the volume of metadata, and not some other issue - then you can determine how best to organise your music to fit within these limits.

Surely the question though if this worked pre-update is what has changed in the indexing post update, and of course this is on the speaker firmware? That’s the part reading through this a couple of times I’m no wiser on… 

Is it related to dropping SMB1 support and is SMB2/3 using more space on the speakers? 

I get that some Sonos speakers are a lot older than others, and have much less storage, so perhaps the best compromise for Sonos is to limit the space to that of the component with the lowest storage, and if you have newer components, or can see your limits, you could replace the older stuff *if* you get close? Rather than the current overly cautious approach of a hard limit based on the worst hardware that can run S2? Also in a multi-speaker setup, the ‘main’ speaker should be the one with the most RAM/storage for indexing if the process itself now uses more space to perform the indexing. When a speaker starts it should query who is the associated speaker, and if it has more resources it should be able to become the associate, probably ignoring Roam/Move speakers. We know Sonos have been messing with this code as it’s currently broken for compilations mainly in 16.3/16.3.1 … 

The info you’ve found is very useful, but I’m not sure we should have to start suddenly worrying about file name length and directory structure in order to index something that used to work. Sonos need to work on efficiency a bit, or allow higher limits on hardware that can support it. Which as you say, means some decent useful error messages when it can’t… along with perhaps a status report saying what % of available metadata space your library is currently at in the about system list. 

I agree this isn’t something we should have to worry about. But I have little to no confidence that Sonos can or will fix the issue, especially given the ongoing debacle.

Prior to the May update my library was setup via the (now broken but still visible in the desktop app) local library option. I don’t know what protocol this caused Sonos to use to connect to the library (https?) but I can only assume that this side-stepped the bug (or caused the index to store shorter path information) because even my S1 system could not successfully index my old combined library via the network option. As soon as I split it, it worked.

So it seems there’s definitely some issue or limitation, likely retained by Sonos for lowest-capability device compatibility, and we can either work around it, or wait for them to fix it :P

I believe the wizard driven add your music library or folder/hard drive used HTTP under the covers once setup. I’ve been reluctant to try them out of curiosity as there’s been little explanation on why even after creating a network share, libraries appear and disappear etc. Also some people with NAS drives have seen issues with music libraries post update too. 

There could (as ever) be several moving parts here, one of which looks like SMB shares use more metadata space than HTTP did, which I guess is because the //computer/share name combination may simply be bigger than whatever was used via HTTP. This may go someway to explaining why the network share solution works for some and not others when switching across. 

It may also be that the dropping of SMB1 may be impacting people who have been switched to SMB2/3 as it may also be using more space for other reasons or simply a bug as referenced by @Ianp above. This might explain why people already NAS drives have seen working libraries now vanish.

Lastly, if Sonos have also modified the indexing code to store more metadata to help the ‘remote’ local search facility in the new app, the space required to store a library index may have grown anyway. 

So you could have 3 things there, not obviously linked, that all contribute to local library seeming to disappear, when as you say, a decent error message saying it’s run out of indexing space would have gotten us here a lot quicker perhaps… 

So I think you may have helped someone here, and perhaps Sonos are aware they need a slightly deeper look at local libraries. 

I still think they should look at increasing the space based on the actual weakest link in the system, and add an index % full to ‘About my Sonos System’ so people know they’re close to trouble and might want/need to upgrade. If I keep growing my library, I don’t mind perhaps needing to update as long as I’m aware. If I don’t want to upgrade perhaps I then have the choice to cull less used music to stay within ‘spec’. 

I got around this problem, to a degree, by splitting a 15,000 song library into two pieces and importing each one separately.  Actually I built two new libraries each containing half the songs in the original library, and left the original as is to use with the Mac Music app.   It will be an annoyance to have to rebuild the two half-size libraries whenever I want to make new material available on Sonos, but that’s better than not being able to do it at all. Maybe they will will eventually fix it.  It’s kind of unbelievable that this kind of small limit would still be screwing up software in 2024, and with utterly uninformative, misleading error messages.  THANK YOU to the OP for explaining what was going on with this!

I have this issue too, trying to connect to my 85Gb, 14000 track library. Contacted Sonos, they did a live login session on my PC and could not resolve or explain. I ended up splitting my music library into 3 separate folders and adding these to the library using the PC controller. Bit clunky and will need some additional management when adding more music, but it works.

Sonos have a ticket open to look at this issue, however based on my experience with them, I don’t expect it to get fixed.

What if I now get not even the error messages mentioned above, but just a spinning wheel for updating Music library that eventually stops and then not even the path of my Music library was copied into the Music library settings in the Sonos controller?

BTW: I only was able to resolve all the 913, 1001, 1002 and access denied errors by renaming my Mac (Sonoma) into a single word name. Got the “no longer available. The device where the music files are stored may not be powered on, or the path may have changed.” error before restarting my Mac, but not any more. Even enabled guest user, gave Sonos full disc access, etc., basically everything mentioned anywhere. My library is 105GB.

It’s also funny to see that a lot of questions are marked as resolved in this community forum, and yet they are not resolved…. and support was useless, wanted me to enable Firewall and add Sonos (which In did), but all of this does not make sense at all. Why do they write a software that only works when tweaking so many other general settings on a Mac? Mimicking a windows share access within the computer, just to access the files from an app???

I downgraded to S1 and everything works again (except my SL speakers). Done with S2, spent way too much time with it, as everyone else here.