Did you try reindexing after disconnecting the One SL?

I got a feeling that it might have spread to other players, since I had problem after the most recent update with manual updates from my Windows controller one day. But I did not have time to investigate it, and instead I disconnected my One SL pair, and since then the automatic reindexing has been working correctlyh.

Ken_Griffithis:

Having manually corrected the characters, did you re-index/update your library within the Sonos App?

I can’t speak for Harry, but why do you think that the non-English characters would be errors tthat need “correction”? They are certainly not an error in my collection!

I think we are perhaps at cross purposes here.. I haven’t mentioned anything about ‘errors’ in my post, nor did I ever suggest that anything needed correcting?

My post simply asks harrysmith0 if he had re-indexed his library after he stated he had ‘manually’ updated his library. I assumed by that he had altered some of the metadata characters that was causing his tracks to not play. If so he may have needed to re-index his library first, before attempting to play the ‘manually’ updated tracks once again.

This morning the Sonos App was back to normal. I can now play titles containing non-English characters. Maybe performing a manual Music Library Update stops it working? There will have been an automatic update during the night.

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.

PS. I meant to mention that to find your Associated Product:

1. go to 'About my system' in your Sonos Controller (mobile or desktop)

2. note the IP address of your Associated Product

3. look up that IP address up from your list of Sonos components. If it's a One SL you will have the issue explained in my earlier post and may wish to force a change to a non-One SL component using my work-round.

To state the obvious, my work-around will not work if you system only comprises One SL(s).

As far as I'm aware, it is not possible to set a component as a static Associated Product and so, like for me when I woke up this morning, my Associated Product had changed back to one of my One SLs, which when I re-indexed my music library, made the artists and albums with international characters disappear again. I had to re-do my work-around and got the temporary fix.

A permanent fix is required to fully resolve this issue and I would imagine is a relatively simple fix to get indexing working correctly on a l One SL as it does across all other Sonos components. If Sonos drag their heals then I will be requesting Ones to replace my One SLs.

I hope this helps others.

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.

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 don’t know the format. They’re just the Sonos app playlists. You add the NAS and it reads the metadata from the files (and the file location, obviously) and then you can add the pieces from your library to a Sonos playlist in the app.

The playlist that is not working correctly (as in: files can’t be found and names are mangled) are just normal M3U text playlists I generate on the NAS.

Sonos playlist are XML files in utf8 format. You can export (and import) them using my iOS app (see profile).

I believe the root of the OPs problem is the encoding of the playlist files, and I don’t know enough about M3U files to speak definitively on that.