beetbox / beetbox/beets

lastgenre: Shortcomings of `_fetch_va_genres`'s plurality logic:**

Open
#6,931 0 comments 0 reactions 0 assignees View on GitHub
lastgenre
Dominant language
Python
Stars
15.7k
Forks
2.1k
Avg merge
4d 21h
Merged PRs (30d)
31

Description

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](https://github.com/beetbox/beets/pull/6474/changes#r3792079386)_

Contributor guide

Open the contributing guide

Research direction

Start in the lastgenre implementation around get_genre(), _fetch_va_genres(), plurality(), and client.fetch("track", item) to trace how track tags become votes. Review the test requested in the linked review context and define expected behavior for uneven tag counts, ties, discarded genres, and logging before adding coverage; done when the selected genres and tie cases are tested and the relevant lastgenre tests pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.