Music library index random errors, with album appearing 3 times each with the same single track

Ok, thanks. I'll call them in the morning to report it.

Just to feed back on this. I did some more searching and realised that the problem was consistent with the Sonos indexing process corrupting due to connection issues with my NAS music library. I tried a few things, of which the main two were turning off the “Extended Attributes” and “DOS attributes” on my music share (which you do within the NAS UI) as they can slow down the ability of Sonos to read the music files, and also turned off the DLNA server that was running on the NAS (which sets up a competing indexing process). Those changes meant that, when I corrected a folder as outlined above, no other album broke instead.

But the music library was still slow to load (especially the album artwork when I looked at the entire list of albums in my library, adding tracks to a queue etc). So I did some more digging and realised that Sonos was causing a network loop on my system, slowing everything down and thereby causing the index corruptions. I’ve always had two Sonos devices hardwired, with others connected via Sonosnet. But I recently had to replace my main network switch and this time went for a managed switch. I was under the impression that, if I didn’t change any settings, it would operate as an unmanaged switch but for Sonos this is not the case. There is a good page on this on the Sonos support website but I had to change a bunch of settings on the switch to get it working properly. The end result was like night and day - near instant responses to the app, instant album artwork loading, no music indexing problems.

So if you have multiple Sonos devices hardwired, and you have a managed switch in your network, I recommend you disconnect all but one and see if that improves things. If it does, great. But if it only improves things for that device and those close to it, but not for ones further away, you clearly need to have more than once device hardwired and you’ll need to make some setting changes on your switch for that to work. 

Hi RLB,

My music is stored on a Server (Unraid). I did turn off the DLNA service and re-scanned, sadly no difference. I only have unmanaged switches on my network and five of the six devices I have are wired, all with fixed IP addresses. I couldn't find any info on Extended or DOS attributes on Unraid. I actually checked a NAS drive that I also have and couldn't find anything about that in its UI either. I did have a quick Google on it and I got the impression it was more likely to do with migration of files from Mac devices. I don't have Apple Mac computers apart from an iPad.

Nevertheless I’m pleased it has worked for you. But be careful, I thought I’d fixed it once, then it magically re-appeared later. I have currently left the error on a couple of albums I rarely play (lucky) and turned off daily library scanning, not a good solution but it works, sort of. :-) 

I agree - I may not have permanently fixed this. I'll post again if the problem returns. 

It is interesting that you also have multiple wired devices. If all the switches are unmanaged that ought to be ok but I do remember Sonos use to post a list of switches that didn't work properly with their system, presumably because of the way they handle STP. It might be worth checking that. 

Also you could try temporarily turning off all the units apart from one, and then trying to fix the music library. If you can, but it fails once you start adding back other devices, I guess that's a marker that there's some kind of networking problem. 

Just one final comment. I was just reading a Reddit thread about networking issues and Sonos, and the poster mentioned that he was using a mesh Wi-Fi system and wiring Sonos devices into the various nodes (presumably with an unmanaged switch at each node). He was getting network loops because while the switches were fine, the mesh nodes weren't handling STP properly. So something else to think about. 

I have ethernet run through the house, and use wired backhaul for my mesh system. And I noticed that if I turned on STP on the ports that had the mesh system connected to it, they would revert to wireless backhaul. That's something to do with the way they check whether the Ethernet or wireless connection is better at startup, which triggers port blocking. I have to turn STP off on the switch ports connected to my mesh nodes to get wired backhaul. So I can believe that mesh and STP could be causing problems for some people depending on the precise network setup.

Wow, you certainly know more about networking than me. Still, at least I know what STP is, thanks Google.

Anyway, I decided to remove all the Ethernet cables and switch over to WiFi, that wasn’t as easy as I thought it would be. Anyway I managed to get all devices connected apart from my Play 3. I then did a library scan and guess what, yes, it was different, but only in that it fixed two broken albums and generated two new broken albums.

l then tried something else, I deleted the library connection from my Unraid server. I realised I had a duplicate library on my Terramaster NAS that I use as a backup to my Unraid server. So I rescanned the library to find the backup on the NAS, it found the library okay but, yes, you’ve guessed it, two fixed duplicate albums, two new broken albums.

To be honest this is getting beyond a joke, all I want to do is listen to my music without becoming a network engineer on the side.

It would be nice to know if Sonos even care about its customers. Perhaps it should say on the box, “Plays music in between you learning network design”.

Anyway I’ve got to go now to plug in all those network cables and hopefully get the play 3 to work again. 😀

Hey RLB!

What kind of NAS are you running? I’m running a Synology, DNLA is off, the software for that ability is not even installed anymore. I have one device on SonosNet, which is a Play 5. I do have a mesh networking system, but it’s never been an issue for me.

--Brian

​@Anthony_6 is this fixed for you? It was ok for over a month but had started again this week for me....

​@CronoCX sorry for the delay. I'm currently running OMV (Openmediavault) on a home built NAS, but I have used Synology in the past. This specific problem is too recent to have appeared when I was using Synology, so I can't comment on that. But the underlying networking technology is the same, so I'd be surprised if it was hardware specific. 

My library is old - I adopted Sonos in about 2007 and built a music library on a NAS then. So, while is has been updated and migrated to new hardware over time, and all the original Sonos components have been long replaced, some of the MP3 files and directory names are nearly 20 years old. I have wondered if some of the long directory names (matching the album titles) are an issue but I don't think so as the problem is so inconsistent and doesn't relate to any changes in the music library itself. 

​@Anthony_6  One final thought - What's the oldest Sonos component in your system? I wondered if there a processing power or memory shortfall when indexing large libraries. I had to get rid of some very old components because they couldn't handle new larger music files. I have a 2nd generation One, 1st generation Move and Roam, and a second generation Sub. Everything else is newer. 

Hi RLB,

The oldest component in my system would be my Play 3, I also have a One Sl, 3 Amps & a Port. I did do a disconnect of all components and ran the system without the Play 3, I was thinking along those lines about memory issues as well. But the problem still existed even when only an Amp was connected.

Hi ​@Anthony_6 Thanks for that. I was wondering if I needed to replace my subwoofer gen2. That would be a costly experiment!

To be honest, owning Sonos has been a costly experience, replacing my 4 x ZP100, which were working perfectly when Sonos wrote them off many years ago. Not to mention the CR200, Okay, so they did give a 30% discount voucher on each one of them (in the end), but it still cost a fair bit to replace them with 3 x Amps.

Sonos do seem to have a habit of annoying their customers. Will they ever fix this issue, are they actually even interested in those of us that choose to have our own music library?

​@Anthony_6 I wanted to give you an update: I replaced my Sonos Sub gen2 with a Sonos Sub 4. The gen 2 was 12 years old and only has 128MB of memory, so very outdated. It was hard to get reliable information on whether a sub was involved in indexing but I got a good black Friday deal and will sell the old one, so the cost to make the change (while high) wasn’t as bad as it could be.

I also deleted all my Sonos playlists, as I noticed some of those were referencing old file paths (and even an old NAS which has been long decommissioned). I then deleted the link to the music library and then relinked, so forced a full reindex. That resulted in 4 problem albums. I changed the name of the directories for each and updated the music library. The albums were corrected but two new ones went wrong. I renamed those directories and updated again. They corrected and no other ones went wrong, so right now I have a proper music library.

I would suggest trying the deleting of the playlists, since that's free. I’m sceptical that changing the Sub made the difference but the memory in that was extremely low, so I can’t be sure. Gemini gave me this table of Sonos component memory - I think it’s accurate. The Sub4 isn’t listed but it’s 512 MB of DDR4 memory and 4GB of eMMC storage. But I’m unsure if this is the issue as it’s not clear whether music indexing runs on the sub as it does on the normal players. 

I won’t be adding any new albums to my music library for a bit, in the hope that Sonos fix any issues with the firmware!

.@RLB

Thank you for that information. I do have a few playlists that I haven't used for ages, i’ll get rid of them and try again. I also noticed from the very helpful list of memory capacities for Sonos products that the Play 3 has only 64 MB compared to the Amp 1 GB, Port 512 MB & 1 SL 512 MB.

I’ll let you know how I get on.

I note that today’s software release contains some updates for Android to help on the tag sorting issue. Have you tried this update? Is there anything to report?

.@RLB

Hi, I did try out removing the Play 3 from the system. I found that I didn’t have any playlist after all, I must have deleted them some time ago. Anyway, I renamed a folder that was showing as only 1 track. This fixed that particular album but as expected a new album was changed to 1 track. I decided to persevere and renamed that folder. Once again the album was corrected only to generate another album with the 1 track error. So anyway I gave it another shot, and guess what, no new errors. I reconnected the play 3 and took my life in my hands. Once again no new errors, however I do now have 3 album folders prefixed with “01” which is what I typically do to for a rename. Fortunately this doesn't show in the Sonos library as it only uses the folder name if you browse by folders otherwise Sonos shows the album by its album title tag.  I then removed the “01” from the folders that had been affected and re-scanned, I’m back to one album showing 1 track. So for me at least nothing seems fixed. 

No, no apparent change. I think it is player firmware updates that are more likely to fix this. I say this because as far as I know all the app software is affected by this annoying bug, Apple, Android and 3rd party Apps as well, such as Sonopad etc.

It seems it's a smaller group of users because many Sonos users don’t have their own in-home music libraries they use online streaming and won’t be aware of this issue. Everyone I know that has Sonos streams content from Spotify etc. The idea of a home library on a server / NAS is totally alien to them. So I guess if you're happy to pay around £12.99 a month for your music then fair play to them.

Because of that I wonder just how much priority Sonos is giving this problem.

Some NAS drives are configured to archive the old copy of any updated updated files. The SONOS indexer usually indexes this folder first, then ignores any other copies. This is very confusing to the user because the updates are ignored. The solution is to disable the NAS archive function and delete the archive folder.

Shares are indexed in the order shown in the library setup. Each share index is completed before moving to the next share. Beyond that the user has no control over processing order. Duplicate files can cause unexpected results. If there are any unexpected duplicates that the indexer encounters prior to the expected, recently edited file, the editing will be ignored. Editing a few files or folders may change the processing order and duplicate files that were ignored the during the last index run will now be visible. I’ve struggled with this a few times when I accidentally (I’m a typo king) saved a file in the wrong folder.