So on Android App version 15.8, but not sure when this first went wrong as I don’t use the Music Library a lot. The App appears to have folder naming issues but only on some folders, Johnny Cash has a nice mix of good and bad ones so I used it as my example.
Thinking it might be an indexing issue I deleted the Library and re-added it, no changes that I could see.
Got distracted by other problems and when I got to my computer today I noticed the Noson app was showing the right folder names.
Can someone at Sonos see if there is anything in the Diagnostic?
Diagnostic Number: 1983430384
I do have a couple Rooms powered down right now, hopefully unrelated to the issue.
Page 1 / 1
To add to the mystery I dug out an old, unsupported Android tablet on v 13.0 of the App and it has the same folder name issues.
Also wrong names on Apple tablet App v 15.6 and v 15.8.1
How odd that only Noson gets them right.
Looking at my file server, a Raspberry Pi with a USB SSD attached for the music.
Since I needed to boot my Windows computer I ran all the updates and then got the latest Sonos App there. Looks like it has no issues with the names.
Went back and poked at the Android App and they are still wrong, but I noticed they are ONLY wrong when accessed from the Folders View in My Sonos. When looked at or played from the Music Library they are fine in both Windows and Android.
Somehow I feel I’ve researched this but to about the bottom of the repair priority list.
Hi @Stanley_4
I too have a Raspberry Pi set up as a SMB file server with my music on it. I was not able to see any occurrences of the issue you describe on my own system, however.
I do notice that my folder structure does not go as deep as yours does, however - it would be interesting to see what would happen if you moved your Johnny Cash folder to “ssd-music” instead of it’s current location, then re-indexed. Please let me know if that does fix things as it would then be fairly easy to describe exactly what the issue is.
However, given that it does not interfere with playback, I think you might be right in that this issue will be low-priority. We can but try, however.
I hope this helps.
To save scrolling for folks the problem turns out to be the “:” in the file names. With it present the Folder view uses a generated short file name, not the original long one. More work, and a fresh post to look into where the problem is coming from.
So on with the process of finding the above!
Poor little Pi 3 really wasn’t happy copying 5+ GB of data from one directory to another over a USB-SATA dongle but it finally got it done.
So with “Johnny Cash” now residing in the ssd-music directory and showing as such in the reindexed folder view I see the same shortened directory names in Folder View but the correct ones when viewing from Music Library.
Diagnostic Number: 1918257488
Directory listings from the Pi look normal, nothing odd visible. (edited to clean up formatting)
pi@pi-3b-2:/mnt/ssd-music $ ls -al
total 404
drwxrwxrwx 5 root root 77 Oct 9 07:01 .
drwxr-xr-x 3 root root 4096 Nov 4 2019 ..
drwxr-xr-x 28 root root 240 Apr 3 2019 Current
drwxr-xr-x 19 root root 4096 Oct 9 07:37 'Johnny Cash'
-rw-r--r-- 1 pi users 404352 May 4 2020 music.list
drwx------ 4 pi pi 31 Dec 28 2021 .Trash-1000
pi@pi-3b-2:/mnt/ssd-music $ ls -al "Johnny Cash"
total 72
drwxr-xr-x 19 root root 4096 Oct 9 07:37 .
drwxrwxrwx 5 root root 77 Oct 9 07:01 ..
drwxr-xr-x 2 root root 4096 Oct 9 07:24 'American I: American Recordings'
drwxr-xr-x 2 root root 4096 Oct 9 07:05 'The Christmas Spirit'
drwxr-xr-x 2 root root 4096 Oct 9 07:10 'The Johnny Cash Children'\''s Album (2006)'
drwxr-xr-x 2 root root 4096 Oct 9 07:09 'The Legend Disc Four: Family And Friends'
drwxr-xr-x 2 root root 4096 Oct 9 07:41 'The Legend Disc One: Win, Place And Show - The Hits'
drwxr-xr-x 2 root root 4096 Oct 9 07:23 'The Legend Disc Three: The Great American Songbook'
drwxr-xr-x 2 root root 4096 Oct 9 07:05 'The Legend Disc Two: Old Favorites and New'
drwxr-xr-x 2 root root 4096 Oct 9 07:13 'The Legend Of'
And now the edited file names appear properly in the Folder View.
However, the names look odd for being a Samba issue as that usually preserves the first few letters of the file name. Before blaming Sonos here I pulled up the music share on a Windows system and there the names with the “:” were also shortened in the file manager and Command Shell.
Maybe Folder View uses the provided/generated file names and the Music Library uses the tag data and isn’t impacted by this glitch?
I’m leaning towards a Samba glitch at this point, more digging needed.
Much digging into the Samba configuration details and code versions turns up the issue. The filename ‘illegal’ character mapping needs to be configured differently in later Samba versions because the ‘mangled map’ option there is gone and replaced with the catia vfs options.
Change to the nmusic] share configuration for just the ‘:’ to ‘÷’ mapping change since that was my only problem character.
vfs objects = catia
catia:mappings = 0x3a:0xf7
If you find you have other character problems here is the full list.
The following will map all invalid windows filename chars: # "\ / : * ? " < > |" # (plus the blank char, not always allowed with legacy clients) catia:mappings = 0x22:0xa8,0x2a:0xa4,0x2f:0xf8,0x3a:0xf7,0x3c:0xab,0x3e:0xbb,0x3f:0xbf,0x5c:0xff,0x7c:0xa6,0x20:0xb1
Hi @Stanley_4
I don’t know if I’d consider this a “glitch” - perhaps just a lack of adaptability. It makes perfect sense that the colons (:) were causing the issue, and I’m sorry I didn’t spot it immediately.
Presumably, your SSD has the Linux filesystem EXT, which does not mind having such characters in filenames. Windows and NTFS definitely do not like seeing those characters - a colon should only occur in a path after the Windows drive letter, and nowhere else. So, when Linux supplies Windows with paths containing such characters, it doesn’t quite know what to do with them, but it knows it can still access those files through the SMB link and does so. It’s just displaying them that generates issues.
Glad to hear you got it sorted out, and thanks for sharing your findings.
Incidentally, you should have been able to move the files in an instant - this effectively just requires a renaming of the files to another directory rather than actual copying - use the “mv” command to move the Johnny Cash folder back to where it was.
I hope this helps.
Nice investigation @Stanley_4 ! Makes sense too as “:” can never exist in an actual Windows path.
Hi @Stanley_4
I don’t know if I’d consider this a “glitch” - perhaps just a lack of adaptability. It makes perfect sense that the colons (:) were causing the issue, and I’m sorry I didn’t spot it immediately.
...
Incidentally, you should have been able to move the files in an instant - this effectively just requires a renaming of the files to another directory rather than actual copying - use the “mv” command to move the Johnny Cash folder back to where it was.
I hope this helps.
Since the file server is sending Sonos the mangled names there is nothing Sonos could do to fix the naming issue, so the ‘glitch’ is on the Samba developers that didn’t do a really good job of notifying users of the mangling change. Been so long since I used Windows for anything but pulling Garmin GPS updates for my Honda I missed it too.
This may issue impact a lot of other folks that use Samba on their NAS devices once they get updated firmware which is why I went into the detail on the vfs ‘fix’ needed for the newer Samba versions. Since it only shows up when using Folder View few will likely even notice, fewer will care.
I agree that ‘mv’ would have been the fast option but since I was intending to hack away at the problem files and didn’t want to have to un-hack them when done I just used ‘cp’ to get a working copy. Dumb move on my part, that I realized once I saw the speed things were moving. My Pi Sonos server is a junk box build, v1 Pi 3, a USB-SATA dongle that came free with a replacement SSD and an antique SSD, so it is far from fast. I should have just had the Pi fetch a fresh copy of the files from my backups.
Once the copy finished I reset the mode of the original directory to 700 locking out all other users, my ‘smbd’ runs as pi, to make it invisible. A reindex brought in the new files and the renamed ones showed the full names.
Made the ‘vfs’ changes to /etc/samba/smb.conf deleted the modified files and changed the mode back to 755 to restore access to the smbd process and did another reindex to pick up the remapped file names.
Hi @Stanley_4
Since the file server is sending Sonos the mangled names there is nothing Sonos could do to fix the naming issue, so the ‘glitch’ is on the Samba developers that didn’t do a really good job of notifying users of the mangling change.
This is what I meant - although I’m used to doing so, I wasn’t being defensive.
Hi @Stanley_4
This is what I meant - although I’m used to doing so, I wasn’t being defensive.
No problem, I was just making it clearer than you did that it wasn’t a Sonos issue.
Same on the more detailed mv versus cp details, a lot of Sonos users have Unix based NAS devices and have little experience doing things under non-Windows operating systems and might appreciate the option to experiment without altering their master copy.