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).
I applied an update to Sonos yesterday. It was over a month since I last applied an update to the NAS.
I believe the NAS is running Linux, so I would expect file names to be in UTF-8. I would not expect there to be BOMs in the file names. (The playlists are actually created on a Windows system, and then copied to the NAS. Thus, the names are originally in UTF-16LE, but that is not a concern to Sonos, as Sonos does not know about the Windows system. And, yes, I did check the names on the NAS before I made my post.)
The issue is not isolated to Playlists, but names are broken when I check the Folders node as well. In fact, here is also some extra confusion, because some artists with non-ASCII characters appear multiple times.
So it seems to be a general problem in how file names are read and stored.
I applied an update to Sonos yesterday. It was over a month since I last applied an update to the NAS.
I believe the NAS is running Linux, so I would expect file names to be in UTF-8. I would not expect there to be BOMs in the file names. (The playlists are actually created on a Windows system, and then copied to the NAS. Thus, the names are originally in UTF-16LE, but that is not a concern to Sonos, as Sonos does not know about the Windows system. And, yes, I did check the names on the NAS before I made my post.)
The issue is not isolated to Playlists, but names are broken when I check the Folders node as well. In fact, here is also some extra confusion, because some artists with non-ASCII characters appear multiple times.
So it seems to be a general problem in how file names are read and stored.
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.
I misunderstood, I thought the problem was with paths in playlist files, hence my speculation regarding BOMs.
...
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.
The contents of the playlists files themselves is utterly dull. The entries are just 01.lnk.mp3 and so on.
Yeah, maybe I should have taken the occasion and called Sonos support today, as it is a day off due to Ascension Day. On the other hand, sitting the telephone queue to Sonos is not particularly entertaining. The exact model of the NAS is a DS213 and the version of the OS is DSM 6.2.3-25426 Update 3.
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.
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!
Nah, it was not that simple. I think incorrectly assumed that the music library already had been updated when I was on the phone with Sonos support. This morning, things were rather worse. The names of the playlists were wrong, and when I tried to play Dire Straits’ second album, Communiqué, selecting it from the Album menu, Sonos could find the file. You may notice the accent in the title (and the name if the file path includes that accent)..
Nevertheless, things are working now. I fooled around and tried various things. While I was at it, I applied the most recent update of DSM, the operating system for the NAS. I don’t know if the upgrade was a required step, or if was just the reboot, or it was some other of the knobs that I tried, but now the file names are displayed properly and the playlists work. Who knows, maybe Sonos and Synology have a conspiracy? :-)
Hello,
I have the same problem…
I tested to change Synology parameter without success
Like @Erland Sommarskog , the filenames is correctly showed but folders don’t.
This is a huge problem. There are several of us using the system and I can't leave it as it is.
Any solutions ?
Regards
At least I am not alone. :-)
What I have found is that in my case things go wrong with he scheduled update of the music library, but if I start the update manually, either from the Windows controller from my phone, the filenames are read correctly. Or at least so it seems.
But that is certainly weird. My speculation is that when the scheduled update runs, player X runs the indexing, but when I start it manually, it is player Y. And this could happen, because different players have different software, since they are different models. Again, this is pure speculation. I looked port 1400 to see if I could see in the logs which players that have been doing the indexing, but it seems that this information is not exposed anymore.
This is my set of players:
2x Play:3 (and of these two is the only with a network cable).
1 Sub, Gen 1 (paired with the two Play:3)
2xSonos Five
2xPlay:1
2xPlay One SL
1 Port
I should also add that I’m confident that the SMB parameter has nothing to do with. The Min setting must be SMB1. I tried to set it to SMB2, and now Sonos were not able to access the NAS at all.
I have only two “Sonos One SL” for now.
For now, I launch indexing manually.
I test this night the scheduled!,
We'll see tomorrow morning
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>
<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>
<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>
<RampantIgnorance> No clue. </RampantIgnorance>
This is not strictly true, but more humorous than the standard “nothing to share” response.
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.
I have this problem. I think it’s the same. None of my music will play if either the track name or the folder holding it contains a non-English alphabet character. I have loads like this.The sonos player correctly displays the names but when you ask it to play the track the Sonos Player says ‘Unable to play xxx -the file xxx cannot be found.’
I tried disconnecting my Sonos One SL as instructed but I still get the error on other speakers. Is there a solution?
I manually updated the music library but it does not fix it for me.
I have this problem. I think it’s the same. None of my music will play if either the track name or the folder holding it contains a non-English alphabet character. I have loads like this.The sonos player correctly displays the names but when you ask it to play the track the Sonos Player says ‘Unable to play xxx -the file xxx cannot be found.’
I tried disconnecting my Sonos One SL as instructed but I still get the error on other speakers. Is there a solution?
I manually updated the music library but it does not fix it for me.
Having manually corrected the characters, did you re-index/update your library within the Sonos App?