Sonos Controller - Duplicate Album Titles

Huh. I never lost access to my local library with S2. Had to update to an updated version of SMB at some point, but never lost access. 

I was referring to the new “Web Controller” at https://play.sonos.com/  only. That is supposed to be the replacement for the desktop controllers at some point.

I found a (well known) fix for this. I very tediously shortened all file names so that total path < 170 and file name < 90. This fixed it for me. 

That’s interesting. I’ve never heard that before. Where can I read about this?

Not sure I’m understanding this.

I provided *one album* to SONOS support that, when indexed just by itself, caused it to appear duplicated.

On my system, the longest total path name for any one of its songs is 106 characters.

The longest file name by itself is 61 characters.

What am I missing?  And ‘well-known’?  What is your source for this?

Sorry, but this is news to me.  Maybe not surprising, but would like to see more info.

Thanks!

One album that I’m having this issue with now is only 70 characters, with spaces, and with the IP Address before the file name. It’s not a character issue. That said, long strings can be an issue, even with Operating Systems :)

//**.*.***.***/C*****/M****/M****/B****/Bear McCreary/Rebel In The Rye

---Brian

A little more background on this one ‘album’ that I’m not sure I shared before.

The ‘album’ is just a bunch of tracks that Paste magazine made available free to subscribers for download years ago.

I downloaded them and created a pseudo-album called Paste Vault and tagged each track appropriately.

The ‘album’ consists of 157 downloaded tracks.  And, as I said above, when indexed just by itself, it produced the three false duplicate album titles.

The number of tracks seemed to be a factor.  I whittled it down to 71 tracks and still got the three duplicates. The first and third consisted of all tracks except track 70, with ‘Various Artists’ as the album artist.  The second had just track 70, with that track artist as the album artist.

When I cut it to 70 tracks, I got TWO duplicate entries:  one with all tracks except 70, and the other with just 70.

Finally, cutting it down to 69 tracks eliminated the false duplicates.

Side note:  the Windows controller handled these duplicates different from the Android controller.

Windows:  queuing any one of the three duplicates gave the same result:  track 70 became number one in the queue, with the other 70 tracks numbers 2-71.

Android:  queue any of the three and you just get the tracks associated with that album entry.

Not sure how this all fits in with the path name/file name conjecture.  Anyway, the Paste Vault album now indexes correctly, once I turned on the Compilation tag in all its tracks.

Bottom line:  seems like a lot of variables at play here, besides simply path name and file name.

Plus ‘.mp3’or something?  But the point is still valid.

I use Bliss, and they told me about that filename limitation. For stupid reasons, I use my own java program to copy music from my local iTunes to my NAS, so I just changed it to print out all the filenames that are too long, then I hand edited them.

But, it turns out that the Albums I found that were bad all had long songs on them - I could have just edited them first.

Also, google will tell you about this issue. Just google “sonos limits on folder name length”. But, as others have pointed out, there are probably other issues at play here….

Me too. Most of my tracks were ripped in the 200x era. I’ve had to rerun the index a few times in order to accommodate SONOS updates, but I don’t recall any major problems. By the way, I usually use the Windows desktop controller for library maintenance, rarely use Android.

 I’ve always kept track and file names as short as practical. Maybe this has kept me out of trouble. I can deal with Playlists and Queues of many, many thousands of tracks.