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

I’m having the exact same problem, with Sonos One SLs (but older devices work fine) and a Synology DS218. I’m indexing manually, and any songs with non-ASCII characters show up, but cannot be played.

I have a DS218 too and its version is DSM 6.2.4-25556.

And yours ?

I still have the problem even after automatic and manual re-indexing 

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.

ok, thanks for communication. We waiting 

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.

Thanks Corry for the update! I already had the One SL as the prime suspect. Based on snm18’s post, I disconnected the One SL last night, and this night the music index was updated completely. I had planned to do a few more tests to verify that they are the culprits, but thanks to you update I don’t need to.

As it happens, I don’t use my One SL much as they are in the kitchen where I don’t play that often. But nevertheless I’m looking forward to the next update which I hope will have the fix. (Based on the assumption that it is a regression. But maybe it is not? I only got my SLs a month ago, and maybe they became masters of indexing after the upgrade because of some shakeup.)

Hi @Erland Sommarskog 

I’m glad to have saved you some trouble!

When indexing, the player that’s “associated” with the controller (a chosen player that the controller app communicates with first) performs the index. Different controllers can have different associated players, so indexing from the app on another device may do the trick. Also, as you’ve experienced, if the associated player is offline then a new one will be chosen for that controller. 

Thanks, Corry! Yes, I was guessing that it is something like that. Although, it’s a little funny that the Windows controller would associate itself with one of the SLs. Naïvely, I would like to think that it would hook up with the player that is wired to the network. But I guess that the Windows controller does not know those details.

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.

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