Surface Bandcamp label-released performers as their own artists#3824
Surface Bandcamp label-released performers as their own artists#3824teancom wants to merge 3 commits into
Conversation
Albums published on a band's page by a different performer (Mortaja on
audiophob, The Green Arrows on Analog Africa) used to be filed under
the page owner. They now get a synthetic artist ID
`{band_id}:{performer_slug}` — scoped per band page so cross-page
same-name performers stay distinct. Synthetic IDs that match the
page-owner's own slug short-circuit back to the real band on resolve,
collapsing any search-time drift before it can persist.
Refs music-assistant/support#5389.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
🔒 Dependency Security Report📦 Modified Dependencies
|
| Name | Skip Reason |
|---|---|
| torch | Dependency not found on PyPI and could not be audited: torch (2.11.0+cpu) |
| torchaudio | Dependency not found on PyPI and could not be audited: torchaudio (2.11.0+cpu) |
| ✅ No known vulnerabilities found |
Automated Security Checks
- ✅ Vulnerability Scan: Passed - No known vulnerabilities
- ✅ Trusted Sources: All packages have verified source repositories
- ✅ Typosquatting Check: No suspicious package names detected
- ✅ License Compatibility: All licenses are OSI-approved and compatible
- ✅ Supply Chain Risk: Passed - packages appear mature and maintained
Manual Review
Maintainer approval required:
- I have reviewed the changes above and approve these dependency updates
To approve: Comment /approve-dependencies or manually add the dependencies-reviewed label.
teancom
added
the
dependencies-reviewed
|
@ALERTua I've been testing this over the past few days, I think this solves most of the label-as-band issues? |
|
Search by "Night Moves" album https://hipdozer.bandcamp.com/album/night-moves, which is Apollo Brown, but hosted on the label Hip Dozer On dev: 
Clicking the artist name: 
On this PR: 
Clicking the artist name: 
I'm not sure this is consistent. Search by "the green arrows" artist On dev: 
On this PR: 
This is definitely good! In this PR, it is possible to search for an artist who is hosted only on a label. It's impossible on the dev. So the only issue I see is that within such an album (e.g., Night Moves), there's no way to go to the label page. But is it bad? Only for the music exploration. And I doubt MA is a music exploration-focused app. Looks good to me. Could be better, but I can't think of a way to make it more comprehensive in the reality of the Bandcamp structure. The number of Bandcamp workarounds is increasing. I hope they are not planning to change any of the core structures, as this code is becoming less and less readable, alas. Maybe, at some point, we will have to rewrite this integration from scratch. But it's OK. |
Builds on the synthetic `{band_id}:{slug}` artist ID for albums released
on a label's page by a different performer. When the performer has
their own Bandcamp band page (Apollo Brown, Mortaja, …), a secondary
autocomplete lookup redirects to the real `{band_id}` so direct-search
and search-by-album-name surface the same artist. When no own band page
exists, resolution falls back to the synthetic ID.
Wired into search, get_album, get_track, get_album_tracks, and the
artist discography listing. Lookups for a batch resolve in parallel and
are cached per performer slug.
Refs music-assistant/support#5389.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
@ALERTua I was focusing only on Mortaja with the first commit, completely forgot to test the other bands. This is now, I believe, an approach that handles all of the various edge cases. I agree it's getting a bit convoluted, hopefully we're nearing the end of the edge-case road? All my fingers are crossed... |
|
In this commit, searching for "Night Moves" brings me the correct album 
But clicking the performer title I am redirected to an unexpected artist page 
which does not have the album I was redirected from, as the album is published on the Hip Dozer label. |
OzGav
left a comment
OzGav
left a comment
There was a problem hiding this comment.
There are a number of other multi-line docstrings to have the first line dropped down to match the indentation of the following text that I didn't put a suggestion on but they all need doing just as a point of standardisation.
- Reformat multi-line docstrings to project standard (description on its own line below the opening triple-quote). - Strip implementation details from docstrings; relocate the still-useful bits to inline comments and add a Sphinx :param: to _fetch_discography. - Log a warning when BandcampAPIError is swallowed in _fetch_performer_band_id so it matches the rest of the file's error-handling convention.
|
@ALERTua I think I've tightened this up as much as I can, without doing full discography o^n-style searches (which would make us bad API users and have a not-great - meaning slow - user experience). If how this branch works overall is - in your eyes - a regression or even just a 'no-op', then let's drop it, no harm, no foul, no use changing behavior and adding code without making some sort of progress. I will truly not be offended. I think this works better for more use-cases, but it's definitely not perfect. |
|
No at the end of the day I think it should work how the users expect, as best as you can. On the false-redirect behaviour you identified, if it can’t be fixed then I think a note in the docs would be required. Will see what Marvin thinks when he reveiws. |
There was a problem hiding this comment.
This looks good to me code wise, but I cannot judge this functionally as I am not a Bandcamp user. I have one question before I merge it. Is it possible to (partly) reuse the helper logic we already have in helpers/compare.py for comparing band and performers?
|
Okay, trying to look at the label-published artists' behavior from the user perspective.
which is a wild guess that is a coincidence. Let's say, we are navigating the user to the wild-guessed artist page, and it is effective in 75% cases. Good enough. We will do better if the users provide us the edge-cases we can fix. What user scenarios do we have more? "Browse". I'm following Analog Africa and I want to brows my "Following" to search for "The Green Arrows". Let's fix this one, make sure the Browse works correctly with both artist pages and virtual artists and all this looks good to me. |
|
I, just last night, left on a 3 week vacation with no laptop (I'm very excited). I can address those when I get back or you can push into the branch, I'm happy either way. ❤️ |
|
Gonna set this to 'draft' just to be able to keep track of things that need my attention. Please mark it as ready for review again when you want me to have a look |
|
Sorry, got no energy to spend even an hour on this now. Things got quite emotionally destabilizing for me here in Kyiv, Ukraine. |
Sorry to hear that. All the best and of course, no rush! |
4 participants
Albums published on a band's page by a different performer (Mortaja on audiophob, The Green Arrows on Analog Africa) used to be filed under the page owner. They now get a synthetic artist ID
{band_id}:{performer_slug}— scoped per band page so cross-page same-name performers stay distinct. Synthetic IDs that match the page-owner's own slug short-circuit back to the real band on resolve, collapsing any search-time drift before it can persist.Fixes music-assistant/support#5389
Depends on ALERTua/bandcamp_async_api#23