epoupon
Same track is assigned to too many clusters, causing radio loop
By using the LMS radio with untagged tracks I noticed long ago that tracks of the same 2 or 3 albums were always being chosen in loop after a while (out of 12000+ tracks). These albums are like sinkholes: when the radio adds them only tracks of the same album will be added, and then the same with the next one, seemingly ad infinitum.
I am new to this codebase and I am still investigating the issue, but I have noticed that the tracks in these albums have been added to a disproportionate number of clusters (8, 7, 6 of 40 clusters, when ~10000 tracks are only in one cluster). This number of clusters per track is constant throughout the tracks of the same album, so naturally when a recommendation of a track of those is found, it will almost always be one of the same album (given they are the ones that build up the most cluster matches).
I have also noticed these loop patterns with more than one album, where the tracks of two albums would alternate.
I have yet to find why are these tracks being added in so many clusters.
I am now tagging my music, however it is taking long as much of my music is not in MB and I'm still adding it. As expected, every time one of these sinkhole tracks gets recommended the radio falls into the loop if the track is still untagged.
I haven't thought of any solution yet as I know little about how these clusters are created, but I thought about opening the issue so that the work can be tracked and a discussion can be had ^^
Hello! This is indeed how the tag based recommandation engine work. It tries to select the tracks that have the most tags in common with what is in the current queue. Therefore if your tracks are inconsistently tagged you can see behaviors like you discribed. However, this should not be infinite, as tracks are never put twice in the queue. Once the album is completely read, it should move to something else. If you want tracks that match a given set of tags, you can just select all tracks matching this set and play them in random order (no need for radio mode in this situation)
yes I noticed it is not infinite, but playing a whole album kind of defeats the purpose of the radio...
In a smaller set of 3 albums I noticed that one of these problematic albums was added to 5 / 7 clusters, and in 4 of those 5 clusters all the tracks were of that album. Maybe there is something wrong with how these tracks are clusterized. How are tracks being clusterized? What criteria/algorithm?
I can look into it as i have it all set up for testing.
Clusters are only used for tags (in earlier LMS versions there were other ways to make track clusters). A cluster is just a tag. Tags are only attached to a track, with no count limit. The tags you see for an album are the top most occuring tags for each category (grouping, genre, etc. These categories are defined in the scanner's settings) If the tracks of an album have a lot of tags (and this album is an exception, other albums just have few tags), then if a track of this album is picked, the algorithm will likely select the remaining tracks of this album, since the probability they share the same tags is high. This algorithm performs better if all tracks are tagged the same way, for example if they all have 1 tag for grouping, max 3 tags for genre, max 3 tags for mood, etc.
Maybe a way to avoid the sinkhole effect is to always use the same set of tags when playing the queue and adding more tracks to it. And add more tags when no more tracks are found with this set. It would still play the whole album if you start with a track of this album, though.