Hi @gsa999
Thanks for your post!
I’m not a programmer, but I would assume that code that did this would not be written by accident, so I’m wondering if there are other tags somewhere than does have “Firehouse” rather than “FireHouse” entry. Did you check Artist and AlbumArtist on both ID3v1 and ID3v2 tags? One of these may be getting used in preference over another, and both may exist side-by-side in one FLAC file.
The fact that the same doesn’t happen with “HammerFall” makes me even more sure that it’s a metadata issue.
I hope this helps.
This is a longstanding issue. To save index space Sonos evidently uses a single-instance string store for tag values. On the first instance of the string it’s written to memory, with subsequent instances then referencing that storage location. The problem is that the string matching is case insensitive.
In this example an instance of ‘Firehouse’ must have been encountered in the index scan before getting to ‘FireHouse’. ‘Firehouse’ was the string that was stored. Because the matching wasn’t case sensitive, the artist tag ‘FireHouse’ looked the same and hence points back to the location of ‘Firehouse’.
The Now Playing metadata displays ‘FireHouse’ correctly as this is fetched from the file at play time, not from the index.
Thanks so much for the reply ratty.
I would never have thought of that! So it looks like Sonos is picking up the track called Firehouse from the first Kiss album !!!
Even though the artist Kiss comes after FireHouse alphabetically I ripped my Kiss CD’s several years ago whereas FireHouse is much more recent, so presumably Sonos is finding the instance of the Kiss track name first based on the file date
Thanks for explaining the issue to me
Kind regards
G
The scanning order isn’t easy to determine. It likely depends on the way the file system is organised on the disk.
If you’re really fussy about this you could exclude the Kiss album and make a (re)scan. Then subsequently add the FireHouse content and update the index.
This is a longstanding issue. To save index space Sonos evidently uses a single-instance string store for tag values. On the first instance of the string it’s written to memory, with subsequent instances then referencing that storage location. The problem is that the string matching is case insensitive.
In this example an instance of ‘Firehouse’ must have been encountered in the index scan before getting to ‘FireHouse’. ‘Firehouse’ was the string that was stored. Because the matching wasn’t case sensitive, the artist tag ‘FireHouse’ looked the same and hence points back to the location of ‘Firehouse’.
The Now Playing metadata displays ‘FireHouse’ correctly as this is fetched from the file at play time, not from the index.
Well done - this is all news to me! I bow to you, sir!
I’m afraid I’m showing my age, at least in terms of Sonos ownership. This issue was floating around the user forums 12 or more years ago.
Yeah, I think you guys got a lot of insight into Music Library when there was no other option for sources! 
How quickly we get used to things these days. I just watched a TV program where someone patiently explained what a 3D printer did. I wondered why he bothered - until I realised the program was 10 years old!
Actually IIRC radio was also an available source, with the list curated by Sonos pre-TuneIn.
I encountered similar this when there was a bug with one of the Beta versions a couple of years ago. It affected random albums across my collection.
In order to ensure all my library was re-indexed. and working as expected, in the Sonos app I added a new shared music folder with a single file in it and removed the one with all my music in.
Then did a re-index and then re-added my main music folder and removed the single file folder and re-indexed again.
My recollection is that this is a ‘feature’ rather than a bug.
I suspect the temporary addition of your new folder tweaked the scanning order serendipitously.
Actually IIRC radio was also an available source, with the list curated by Sonos pre-TuneIn.
That makes sense - I think I was listening to SHOUTcast on WinAMP over 20 years ago. “Grove Salad” - still running today and on TuneIn!
Actually IIRC radio was also an available source, with the list curated by Sonos pre-TuneIn.
That makes sense - I think I was listening to SHOUTcast on WinAMP over 20 years ago. “Grove Salad” - still running today and on TuneIn!
If you mean SomaFM’s Groove Salad then it’s not on TuneIn (or Sonos Radio) in the UK owing to legal issues. It’s on myTuner Radio though.
If you mean SomaFM’s Groove Salad then it’s not on TuneIn (or Sonos Radio) in the UK owing to legal issues. It’s on myTuner Radio though.
I did indeed! Ah yes - I think it’s been a while since I listened. I have a dead My Sonos link to it on TuneIn.
On other Music Library Index fumble can be caused by a NAS drive’s Recycle bin. In case of duplicate tracks, the Indexer ignores the second and following occurrences. If the tag editor places the original copy of an edited track in the recycle bin and the recycle bin is scanned first, the old track is discovered first and the updates are ignored. (the indexer does not check every character in the metadata) This can be very frustrating for the user because updates are seemingly ignored and the user can prove that the updated data is being ignored. The NAS typically will allow the recycle bin to be disabled.
