Thanks for the background. Why would they introduce a 'fix' to only one component?

Not only is this a massive step back in my opinion (as there are ways around the SMBv1 issue) but it now makes a rock solid Sonos experience unwantedly flakey.

I was seriously unimpressed to hear back from Sonos support today to let me know this is a known issue when yesterday the individual was happy to blame my Synology NAS! This individual was unable to give me an timescale for a fix but suggested I re-tag my music library! 

So not only was my time wasted investigating non-existent issues with my NAS but apparently I have to spend further time identifying and changing the metadata for my entire music library!

The main point here is that the way my artists, folders, files etc. are tagged IS CORRECT - Anders Trentemøller's surname is not Trentemoller so why should I re-tag my music to overcome an issue caused by Sonos? This is especially unwelcome advice when Sonos supports the correct character set when the music is not indexed using a One SL as the Associated Product.

Why introduce inconsistency into the ecosystem?  I've invested too much money and time into my Sonos system to 'lose' large chunks of my music library and I don't take being fobbed-off kindly. 

I also reject the implication by Sonos support that my time is of little importance of value and that I should spend it changing my music library so it works with a poorly regression-tested software release.

I made a test and changed the settings for the music library, so that I removed the share for the playlists on the NAS, and instead I mapped the music library to read the playlists from my Windows machine. This changed things to the better, so that file names now appears correctly in the Sonos app, and the files on the playlists are visible.

So it appears that this is only an issue when reading files from Linux, or possibly certainly flavours of Linux.

While this is a workaround for me, I still prefer to have everything on the NAS, which has a higher uptime than the Windows machine.

This is not strictly true, but more humorous than the standard “nothing to share” response. 

<RampantIgnorance> No clue. </RampantIgnorance>

<Rampant speculation> so the SL has a different SMB stack than every other device? Perhaps it is a sign of a “modern” SMB implementation that will eventually support SMBv2 or v3? </RampantSpeculation>

Hi @Erland Sommarskog and others!

We are aware of this new issue and are working on a resolution. As yet, we do not have a time-scale for the fix.

This issue is affecting Sonos One SLs only. If you’re unable to index successfully, you may be able to by switching off any SLs. It also only seems to affect NAS shares (or as you’ve discussed in this thread, Linux).

Apologies for any inconvenience.

It is equally broken if your NAS share is a Windows Server 2019 box.

FYI from debugging what filename the One SL is requesting, my guess is that it is scanning/indexing correctly in UTF-8 but sending the encoded name request as (I’m guessing) ANSI, which the fileserver perfectly reasonably cannot then find.

The work around is to start music on another (non-SL) speaker and bring the SLs into that group. The other speaker will be group leader and will request the correct filenames. You can then zero the volume on that speaker, leaving the SLs playing the music as desired but within that group.

I've experienced the same issue where the artists and albums containing non-English characters e.g. Scandinavian we're not appearing in my music library, despite having been visible previously.  After lots of testing I can confirm that the issue has nothing to do with my Synology NAS and relates to Sonos systems where the Associated Product is a One SL.

I have 2x One SL in my system and one of these was my Associated Product. Each time I updated the music library I had lots of missing artists & their albums from artists such as Trentemøller.

After some testing, the following work around resolved the issue for me:

1. I powered off both One SL and restarted the Sonos Controller which forced a change to the Associated Product.

2. I then powered on both One SLs and manually updated my music library and the missing Artists and albums reappeared.

It is disappointing that this issue has been known about for a couple of months and Sonos have not yet provided a fix. Hopefully a fix will be provided very shortly.

I have contacted Sonos to ask them to let me know when this issue will be fixed or to arrange to replace my One SLs with Ones.

I hope this helps others in the short term and that Sonos provide a long-term fix.

The One SL has  different SMB stack than every other Sonos device. The speculation is that this is to finally fix the SMBv1 problem that NAS users complain constantly about for years.

Moral: be careful what you ask for.

This new stack is clearly broken, and as I assume Sonos did not create it, they have to wait for the owners of whatever package they picked up to fix it (I assume it is Samba, the old stack came from them and what a pain that was to integrate into the build system).

Or they could put back the old SMBv1-required stack.

What codepage are your playlists in? Is there a BOM on it? Was there a Synology update recently (I ask because I’d be surprised if Sonos changed something as frozen-in-time as imported playlists).

When the app opens or reconnects, it says “Hello?” and whichever player responds “Hello” back first is the associated player. If the wired unit is busier than another player with other tasks (likely), then it may not be first responder.

Hi everyone,

Just wanted to let you all know that this issue has been resolved in the latest S2 update (13.3).

Please update your players and let us know if you continue experiencing this issue by contacting our customer care team via phone or live chat.

I called Sonos support to report the issue, but lo and behold: they had a solution! In my NAS (a Synology DS213), I was told to go to the Control Panel, and then select File Services. There is a tab SMB/AFP/NFS. In this tab, select Advanced. In this UI there is “Max SMB-protocol” and “Min SMB-protocol”. They should be set to SMB2 and SMB1 respectively. I applied these changes and restored the setting for the music library to use the NAS for the playlists - and now things are working properly. Well, almost. Folder names with non-ASCII names are still broken, but that is less of an issue, since I don’t use folders that much, and it is still possible to get to the tracks.

Hats off for Sonos Support!

I misunderstood, I thought the problem was with paths in playlist files, hence my speculation regarding BOMs.

I know nothing about Linux, but I do know that Sonos generally uses UTF-8 for its strings, as that is how UPnP works. I assume other clients of this NAS see those files correctly?

Could Sonos have finally updated the Samba client in S2 to no longer need SMBv1 and introduced this bug? That is the only reason I can think of they would touch this code with a 10ft barge-pole.

You should probably create a diagnostic and submit it to Sonos support, and also share what NAS you are using for others to chime in.

Hi,

I’ve bought three Sonos One SL speakers and this issue has not been completely solved.

There are tracks in the music library on my NAS (which is basically just an Intel NUC that runs a minimal Debian install to provide the music Samba share) that have accented letters in them, both in the metadata and in the file names.

When I import the music library into the Sonos app on iOS, everything seems to be fine: names/titles are correct and files are found and played.

However, this server also generates an m3u playlist every night, with a few hundred random numbers. In the Music Library, this playlist can be found under “Imported Playlists”. When I open this playlist, files that have filenames with accents in them cannot be found, the name is garbled, and the cover image is not loaded.

So the issue may be fixed with regard to library indexing, but not with regard to playlists that are imported from the share. (Songs in the imported playlists that have no non-ascii and no accented characters in them do work as expected.)

Sonos confirmed in another thread that the recent update fixed this bug.

Now I have gotten two updates to Sonos since this thread - alas the problem is still there. I can work around by requesting a manual update of the music library - for some reason the scheduled one runs on one of the One SL. Too bad for those who only Sonos One SL and no other player.

After the update that came a few days I go, I don’t see this problem. Hopefully, this means that the issue has been fixed. But since it was only Sonos One SL that was affected, and I got a few more other players, it could also be that the scheduled updated moved to a different player after the installation of the new version.

What encoding is the playlist in? Does it have a BOM? Suggest making it utf8 with a BOM, but I don’t honestly now what formats are supported.

Sonos doesn’t release any dates for fixes, which makes sense, as sometimes tracking down obscure issues doesn’t respond to calendar dates.

We know about them if/when they give release notes to us. Or if our personal testing confirms it’s been fixed, which has been more the case since the change last year in the person/policy regarding release notes. The new regime thinks less is more. 

The playlist is generated by a bash script under Linux: it basically finds all the FLAC-files in a folder (including subfolders), lists them, then shuffles the list, and picks the first 250. The result is saved to a file, prefixed with the URL to the server and share. This effectively creates a playlist with 250 random pieces.

The file is in UTF-8 format. I can try to add a BOM, but (I can’t remember) I may have tried this already.

The problem is “fixed” when I convert the file from UTF-8 to ISO-8859-1 (“Latin-1”) after saving, but this often fails if the files contain an accented letter that has no equivalent in the extended ASCII set.

I’m thinking of adapting this script, listing all the FLAC’s I have and running it through “grep”, which can highlight non-ascii characters for me. Then I can remove those letters and for example replace “ü” with “ue”, etc, like is often done in Germany.

Like mjvanthoor I create playlists every night, and I also have plenty of items with letter outside the ASCII range. However, I don’t have the problem mjvanthoor has, since I use “boring” names. A folder with a playlist has a name like 1665457592_1. (Current Unix time and a running number for the day.). Inside these folders the files are named 01.lnk.mp3, 02.lnk.mp3 etc. Despite the name, they are physical copies of the files. I think I tried to use sym/hardlinks originally, but I did not get it to work. As for having the real titles in the file name - I don’t recall if I ever tried that and it failed because of the character set. And if there were such an issue, was that with Sonos or because I used Perl and Perl is not good with Unicode in file names. It was many years ago, and the system I have works for me. I don’t have to see these boring names in the Sonos application, but here tags, folders etc display correctly without issues.

The reason why my setup isn’t working with Sonos is because the filenames in playlest get mangled on import. I’ve gone and just removed all the diatrics from the filenames, and now everything should work. I could also have tried it your way: generating a list of 250 files like I do now, copy those files into a folder with a random guid-like name, and then save the playlist to point to those files.

That would certainly work, but the one thing I don’t like about this setup is that I would need to copy about 3GB of music every night. (About 12 pieces per hour, for 12 hours is 144 pieces; say, 150 for a nice round number, at 20 MB per FLAC file, comes down to around 3GB.)

The strange thing is that Sonos does understand diatrics in file names, because the “normal” playlists (made through the Sonos app) work fine. They just don’t work when importing a playlist from the NAS.

I don’t use the normal playlists, but do they have the same format as the playlists you have on the NAS? I would guess that they have an internal format.

I also have this problem. When will it be fixed?