While refactoring and adding a test that was aksed for in review I realized shortcomings in the "various artists most popular track genre voting mechanisms" that happens in the artist stage in get_genre():
- Uneven vote weight per track:
client.fetch("track", item) can return multiple tags (per the count config), and all of them are added to item_genres. A track with 3 returned tags casts 3 "votes" while a track with 1 tag casts only 1, so the result skews toward tracks that happen to return more tags rather than reflecting one vote per track.
- Silent, arbitrary tie-breaking:
plurality() uses Counter.most_common(1), which on a tie just returns whichever genre was inserted first into the counter (i.e., whichever track was iterated first). There's no indication in logs or behavior that a tie occurred — the "winner" is effectively an implementation detail of dict/Counter ordering.
- Single genre discarded, no fallback for ties: even when multiple genres are equally popular, only one is returned (
[most_popular]), discarding information that could otherwise flow through the normal whitelist/canonicalization/count pipeline used elsewhere in the plugin.
- No visibility for debugging: there's currently no log signal to help a user understand why a particular genre was chosen for a VA album when the vote was close or tied, making it hard to diagnose "wrong" genre picks.
Originally posted by @JOJ0 in #6474
While refactoring and adding a test that was aksed for in review I realized shortcomings in the "various artists most popular track genre voting mechanisms" that happens in the artist stage in
get_genre():client.fetch("track", item)can return multiple tags (per thecountconfig), and all of them are added toitem_genres. A track with 3 returned tags casts 3 "votes" while a track with 1 tag casts only 1, so the result skews toward tracks that happen to return more tags rather than reflecting one vote per track.plurality()usesCounter.most_common(1), which on a tie just returns whichever genre was inserted first into the counter (i.e., whichever track was iterated first). There's no indication in logs or behavior that a tie occurred — the "winner" is effectively an implementation detail of dict/Counter ordering.[most_popular]), discarding information that could otherwise flow through the normal whitelist/canonicalization/count pipeline used elsewhere in the plugin.Originally posted by @JOJ0 in #6474