Sonos Controller - Duplicate Album Titles

​@MoPac Compilation tag is a Yes/No, flag added in DbPoweramp via a check box on the top bar with other album details between Genre and Date when ripping and can be added through power amps 'Edit ID Tags' functionality (mp3tag too). On ripping it automatically checks if metadata selected has multiple artists.

For my part duplicates, as has been observed here, do move around/alter across indexing so in a large collection it can be a bit hit and miss finding them! I have found that they are not biased towards any given album(s)/index position/date added or compilation status.

Primary issue I am seeing with compilations is that I am using specific album artists such as 'Various Artists', 'Various Artists - Soundtrack' and 'Ministry of Sound' for some of my compilations and neither show in the Android app search results under artists but do in the PC and Phonos apps(*). Removing the compilation tag has no effect so this, and the Phonos/PC apps(*) working, would tend to point away from tagging issues.

I have however tried various re-tagging and file renaming exercises in an attempt to resolve both issues but with no success.The chosen associated speaker during the indexing is also of have no noticeable impact.

I have a relatively large library of around 2,000+/- artists and 3,500+/- albums and 50,000+/- tracks, with about 380 albums spread across the above compilation artists. I have seen duplicates across all of them but am indexing fairly regularly at present and duplicates do not remain very static, the compilation search results however do.

I am sincerely hoping that the resolution to both these issues lies in the same, or a related, fix and will be addressed in one update 🤞

(*) As a note, my tagging was fine with S1 app too where I didn't notice, over a period of many years, either issue.

​@User117655 

 Thanks.  I have a better understanding of the issue now.  Guess I’m so busy exploring Dolby Atmos music that I haven’t been using Sonos to play my local library that much.  For local library play I have a stereo system that outperforms Sonos.

Just as an addition, not something I am falling foul of but just saw it on a friends system with m3u playlists:

* When indexing ensure the NAS recycle folder for the share is empty. It's contents will be included by Sonos when indexing if you map to your NAS at the share level.

If recycle is enabled on your share folder(s) and the share contains a #recycle folder (Synology for ex.) in addition to your music folder(s)/files then ensure it is empty. Or at least does not contain music files.

This could lead to ghost/duplicate files.

I have not gone back to look but if this has been mentioned previously my apologies...

Thanks for mentioning this.  I had also noticed this some time ago and took steps to make sure it wasn’t an issue for me, but it’s worth noting here.  Very good point!  :)

While this might be the case in some cases, it does not for mine. Right now my “Recycle” bin only has some JPGs in it and I’m still seeing duplicated albums.

--Brian

 I think with the NAS Recycle folder you could conceivably have duplicate albums with the same tracks in each album.  The duplicate album issue in Sonos is different in that there are duplicate albums, but there are different tracks in each of the albums.

The NAS recycle bin issue usually results in tag updates being ignored. The indexer will ignore the second and following occurrences of a file. If the user edits a file, but the file is first encountered in recycle, the edits will not be visible to the user. Duplicate files in the regular list can also result in issues. For example, if the user accidentally created a second copy of a file, edits the primary copy, but the secondary copy is first presented to the indexer, the edits are seemingly ignored.

Other than the indexer fully processing one share before moving on to the next, the user has no control over processing order. This can result in interesting issues if the index is full before all tracks can be included or the indexer terminates due to an error. Recently edited tracks are typically presented to the indexer last. Consider the case where there is only room for four more tracks, we are attempting to add eight tracks a-b-c-d-e-f-g-h, and there is a foreign character in track ‘e’ tags that will cause the indexer to terminate early. If processing proceeds in the order shown, ‘e’ through ‘h’ will be missing, but on the next run, since the user has no control over processing order, and ‘e’ is encountered as one of the four, different tracks can be ‘missing’ on each index run. Depending on when the NAS presents track ‘e’, dozens or hundreds of tracks could be ‘missing’.

Typically the user wants to verify the recent edits and will notice any issues here, but there may be other issues to be discovered much later.

If you are running into illegal character issues with your NAS you might try the "catia vfs" configuration options to remove them from the SMB stream without requiring file or folder renaming.

Scroll down to the October update section:

https://stan-miller.livejournal.com/650.html

This is all very interesting, but not related to the problem which this thread (and this one Albums have suddenly started to behave strangely.) is about. Which is an actual bug introduced in the S2 indexing which Sonos has yet to identify and fix. It is not caused by incorrect tagging or duplicate files. Nor file name strangeness. 

But then that would indicate that Sonos is looking in other folders it does not have access to. You can assign one path to the Sonos software for indexing. MAYBE if your music was at the Root level, which I doubt many people do.. Again, what kdowing said is correct. “This threrad is about Which is an actual bug introduced in the S2 indexing which Sonos has yet to identify and fix. It is not caused by incorrect tagging or duplicate files. Nor file name strangeness.” I’ll also add that it does not happen on S1, or, for that matter S2 software before the botched May 2024 update.

--Brian