Recent Sonos update is broken on non-ASCII characters in file names

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.

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 also have this problem. When will it be fixed?

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. 

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.

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.

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

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.)

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.

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.