Fixing the "The device where the music files are stored may not be powered on" error.

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.

Troubleshooting

As you’ve probably guessed, the solution had absolutely nothing to do with (deep breath!): SMB versions, file sharing configuration, user permissions, network configuration or router settings.

I created a new share (before anyone gets excited this was done exactly the same as the existing share), copied a single album into it, completed the library setup process using the MacOS desktop app, and voila!, it instantly indexed. So this was not a file sharing issue (told ya), but something was behaving differently given I'd not added to my library since the update. I added half the library to the new share and that indexed successfully too, but adding the other half, either together or as part of an additional share, resulted in the error again. So some sort of library restriction or content issue seemed logical.

After trawling this forum and search engines I found posts about the local library limit (65k tracks), which at 19k tracks I am massively under. I also saw a couple of posts about supposed metadata character limits for album, artist, genre, track name, and file path information, although I note there appears to be no formal documentation or recommendation from Sonos regarding these. I extracted a list this information from my Apple Music library, and found dozens of files exceeding one or other of the supposed limits. So I added only those albums and repeated the indexing, which succeeded. So the length of the individual metadata wasn't a problem. So, perhaps it was just the cumulative volume of metadata? So, I renamed around 6k tracks from audiobooks, replacing the verbose chapter names with simple disc-track naming (e.g. 01-001.m4a). Fortunately this was relatively simple using MacOS Finder's bulk renaming function and the files still contained the album, artist, track name and genre information used by Sonos library indexing. Finally, I added everything back into the original share, and ran the indexing process again, and this time it was successful. So the issue was that the cumulative file path and metadata exceeded a Sonos limit, but crucially, the app is incapable of outputting any remotely useful error message to inform the user of this.

I've now split my library into two shares. One for the audiobooks (rarely added to) and another for music. This way, I can more easily take action to prune the filenames of the audiobooks should it become necessary again, and it will be easy to tell if ever the music share metadata becomes too large, as the two shares have different names that will be surfaced by the cryptic error message.

Resolving the error

My library is managed by Apple Music, which automatically names imported files using the track name from the embedded metadata. Others with similarly sized libraries may not encounter the limit if their library management involves naming files using disc-track numbering only.

It's notable that this issue only presented after the update, appearing only to impact sharing over SMB2/3, as the same library indexed perfectly prior to the May update.

1. Does your error message match the screenshot?
2. Have you setup your file share per the Sonos guide?
3. How many tracks do you have?
4. Do your files have proper names e.g. "Escape from the City of Angels.m4a" or are they simple disc-track names e.g. 01-001.m4a?

If you think you may be exceeding the library data limit:

1. Try moving a portion of your library outside the shared location.
2. Repeat the indexing process. If it works, you're likely hitting the data limit.
3. Consider renaming your files in the format 01-001.m4a. Bear in mind that if you do this and you use Apple Music or iTunes you will need to disable the "allow Apple Music to manage my library" setting - with it enabled the application will name your tracks with proper names.

My suggestions to Sonos:

1. Please improve your error messages. You're clearly handling this exception, so you should be able to provide a unique error number and message to the user so they have a fighting chance of fixing the issue.

2. Please improve your documentation. I get that 90% of your customers don't use local libraries, but 10% of us do, and if you can't or won't adjust the limits on the volume of metadata, so that you can continue to support older, memory-limited hardware, then please provide some formal documentation around metadata limits, and preferably some recommendations for how to maximise the number of tracks that can be successfully added within your data limit.