Draft: Add support for multiple artists per album/track
HEAVILY WIP
Albums released by a single artist may contain songs that feature other artists, and similar some albums are released by a group of individual artists. Funkwhale's code base doesn't deal with this well currently: Artist information may silently be dropped, or "composite" artists are created as a workaround (instead of "artistA" and "artistB", "artistA/artistB" is created as a single artist). This makes locating albums by artist harder (since feature tracks generally aren't found), and it leads to split album entries (since the track artist propagates up to the album artist).
This MR addresses all of the above, in parts by fixing existing logic bugs in the way album artists are handled, but mainly by adding proper support for storing multiple artists per track and album in the database. There's many small pieces that need to fall in place for this to happen consistently across the project, so I'm creating this MR early so we can address all of them. Let's build a functional prototype first so we understand what parts needs adjustment; I plan on doing a cleanup pass over the commits after that.
Changes:
- To be listed.
TODOs for the functional prototype:
-
Fix logic bugs related to album artists -
Add artists
field tomodels.Track
andmodels.Album
-
Add artists
field tomodels.Channel
? -
Count tracks_count
returned by/api/v1/artists/
using the newartists
field -
Include feature tracks in /api/v1/tracks/?artist=14
(frontend:/library/artists/id/
) -
(low prio) Store artists in the right order (currently, the database field is unordered) -
(low prio) Populate models.Album.artists
properly- The currently used "album_artist" audio tag from the source file doesn't provide individual artist information
- Instead, use the
mbid
s and look up the artists. This may require a lookup on musicbrainz if local entries don't exist while parsing.
-
Fix all tests -
Database migration on update: -
Turn the old artist
field in Track/Album models to the newartists
field- This migration logic will be nontrivial: Artists since we should re-parse the tracks' metadata to populate the artists properly
-
Prototype migration by splitting artist
on/
-
Proper migration by reparsing track metadata - NOTE: The default migration process should be fast enough to work on big instances. An optional migration path could be offered via music/management/commands
-
Merge album entries that are currently split (due to improper album artist handling) into the single album entry they should be
-
-
API: -
Should the legacy artist
field in/api/v1/tracks/
(and others) be kept around for backwards compatibility? -
Should the new artists
field in/api/v1/tracks/
(and others) be enabled by default or should it be opt-in by the API consumer? -
Adjust manage
API for multiple artists
-
-
UI: -
Display all artists as separate links/chips across the UI -
Use multiple artists for track queue persistence -
Use user
icons instead ofusers
when displaying artist chips (e.g. on/library/artists/23/
) -
Infer correct number of tracks and albums to be displayed in /library/artists/id/
- Albums are tricky: Being featured in a track generally does not imply being an album artist. Might need to rephrase "x tracks in y albums" to "x tracks and y albums", and hide the album count if it's 0
-
-
Django admin: -
/api/admin/music/album/ should list artists
instead ofartist
-
-
Identify remaining TODOs -
Adjust all pieces of the UI that display artist information -
Adjust all filters that use artist information
-
Migration plan:
-
This MR should only change the database schema, expose a new API to access all artists, and provide a backwards compatibility API for single-artists -
UI changes will be moved to another MR -
A final MR will remove the legacy single-artist API
Related issue reports:
This Merge Request includes:
-
Tests -
A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)