starred/Lidarr

Fork 0

mirror of https://github.com/Lidarr/Lidarr.git synced 2026-03-02 22:56:57 -05:00

Metadata Artist ReTag strips 'Feat.' or '&' and Secondary Artists #1119

New issue

Open

opened 2026-02-20 01:12:21 -05:00 by deekerman · 11 comments

deekerman commented

2026-02-20 01:12:21 -05:00

Owner

Originally created by @Alan111S on GitHub (Sep 11, 2020).

Is your feature request related to a problem? Please describe.
When retagging files, the Artist (as in Contributing Artist) is stored with only the Main Artist. Any Secondary Artists or Featured Artists are removed. e.g. 'SexyBack' is now tagged with Artist 'Justin Timbalake' instead of 'Justin Timberlake (feat. Timbaland)'

Describe the solution you'd like
I'd like Retag to keep the proper Artist List from MusicBrainz. Also, would be useful to add a new token {TrackArtist} to use with the Rename function. As you can see in the attached the filename has the Artist replaced with Various Artists.

AB#346

Originally created by @Alan111S on GitHub (Sep 11, 2020). **Is your feature request related to a problem? Please describe.** When retagging files, the Artist (as in Contributing Artist) is stored with only the Main Artist. Any Secondary Artists or Featured Artists are removed. e.g. 'SexyBack' is now tagged with Artist 'Justin Timbalake' instead of 'Justin Timberlake (feat. Timbaland)' ![Retag Before](https://user-images.githubusercontent.com/17717393/92856554-e8d66f00-f436-11ea-9b95-df0a17e09dd5.PNG) ![Retag After](https://user-images.githubusercontent.com/17717393/92856559-ea079c00-f436-11ea-8f8d-778ba55fd73a.PNG) **Describe the solution you'd like** I'd like Retag to keep the proper Artist List from MusicBrainz. Also, would be useful to add a new token {TrackArtist} to use with the Rename function. As you can see in the attached the filename has the Artist replaced with Various Artists. [AB#346](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/346)

deekerman added the

Type: Enhancement

label

2026-02-20 01:12:21 -05:00

deekerman commented

2026-02-20 01:12:22 -05:00

Author

Owner

@Alan111S commented on GitHub (Sep 11, 2020):

Suppose this might be useful:-

@Alan111S commented on GitHub (Sep 11, 2020): Suppose this might be useful:- ![MusicBrainz](https://user-images.githubusercontent.com/17717393/92857772-88483180-f438-11ea-8900-ca9297e142fd.PNG)

deekerman commented

2026-02-20 01:12:22 -05:00

Author

Owner

@Chuchodavids commented on GitHub (Dec 15, 2020):

Having this same issue with the metadata tagger. This is driving me crazy.

@Chuchodavids commented on GitHub (Dec 15, 2020): Having this same issue with the metadata tagger. This is driving me crazy.

deekerman commented

2026-02-20 01:12:22 -05:00

Author

Owner

@elwayman02 commented on GitHub (May 12, 2021):

Seeing the same issue as well. I really wanted to use Lidarr to clean up my tags and filenames, but dropping the featured artists from my tracks is a big regression in my metadata.

@elwayman02 commented on GitHub (May 12, 2021): Seeing the same issue as well. I really wanted to use Lidarr to clean up my tags and filenames, but dropping the featured artists from my tracks is a big regression in my metadata. ![image](https://user-images.githubusercontent.com/1325482/118071590-eed17680-b35c-11eb-8ae0-15f9661818a5.png)

deekerman commented

2026-02-20 01:12:22 -05:00

Author

Owner

@FinalDoom commented on GitHub (Apr 5, 2022):

Still present in current Lidarr. Pretty annoying TBH. Especially since it affects the TrackArtist naming tag. One of these days I'll look at fixing it, but no promises.

If anyone who knows the code but doesn't have time wants to give some pointers where to look to fix, that'd help greatly.

Edit:

Some notes/findings:

AudioTag.cs:572

            var artist = tag.AlbumArtists?.FirstOrDefault(); // This could be a problem

            if (artist.IsNullOrWhiteSpace())
            {
                artist = tag.Performers?.FirstOrDefault(); // This could be a problem
            }

And the related class it's filling. Since it only allows a single artist. Maybe this just needs to be the full string, maybe it needs to be an array. MusicBrainz does define different separators though as well--Where album artists are created by joining on '/', that might not be most correct where MusicBrainz defines '&' or 'feat.' etc.

Also a couple more notes/questions:

In TrackFile.cs

        // These are queried from the database
        public LazyLoaded<List<Track>> Tracks { get; set; }
        public LazyLoaded<Artist> Artist { get; set; } // This seems like it should be plural but the Track in Tracks should also? where should it be plural? Probably just in the Track object.. what is this? Album artist? But that's stored in the Album
        public LazyLoaded<Album> Album { get; set; }

In Track.cs

        public int ArtistMetadataId { get; set; } // This needs to be plural
...
        [MemberwiseEqualityIgnore]
        public LazyLoaded<ArtistMetadata> ArtistMetadata { get; set; } // This should also be plural

Track.cs is where it really seems like the multi-artist stuff should be, to me. But this is just a first look. It's probably also where the joiners should be stored. But that's a more complex mapping, as it's given by MusicBrainz as "Artist" [ + "joinphrase" + "Artist" ]*

For example, https://musicbrainz.org/ws/2/recording/40d5e635-ed5f-478a-9deb-8b30d752bea6?fmt=json&inc=artists has 3 artists, joined by "feat." and "&"

There's a number of spots where Lidarr is deleting information. For example, on the track https://musicbrainz.org/release/3cd2afee-1aca-4374-88b8-9aeef4317d90/disc/1#7f43cf9c-6ca6-40ef-ad6f-2d44dc7cf723

Note that it didn't touch Artists, Artist Sort order; while it did remove information from Artist (text including feat. etc.). It's got better information for Date, Genre.

Also of note/related to the ticket, MusicBrainz Artist Id should include all track artists' IDs.

An open question: Do we need to record the "joinphrase" for artists on the track, or can we assume A "feat." B [comma] C ... [ampersand] Z? My hunch is we can't assume, as it could also be "A & B" as a duet, not featuring.

As a corollary, record label should include all labels.

Some other info on inconsistencies: (After applying Picard's changes, excluding Date and Genre)

Note repeated tags, but also inconsistency with dates. The YEAR tag should not include -01-01 (useless information) that Lidarr is adding. And ORIGINALYEAR and ORIGYEAR values are swapped by Lidarr. Picard uses the longer tag name for a release year value, and the shorter tag name for the release date with month and day, while Lidarr does the reverse. I know the spec is not super specific about this, but for a fully automated system, it should match Picard IMO.

As far as work that needs to be done, Track objects (database etc.) need to include all artist IDs, and either joinphrases or a text representation for filling out ARTIST. Joinphrases would be less data to store, as we can store IDs and fetch name/sort/etc. as needed. Corrolary multiple mappings would be good to change as well, since it's a similar operation. All I'm seeing there right now is PUBLISHER (Record Label). There's also some missing tagging RE Artists and Artist Sort Order that Lidarr could/should be setting.

For now as a workaround, everything needs to be handled in MusicBrainz Picard. It appears that Lidarr is using flawed artist processing for the TrackArtistName field as well: so renaming is broken in Lidarr too.

@FinalDoom commented on GitHub (Apr 5, 2022): Still present in current Lidarr. Pretty annoying TBH. Especially since it affects the TrackArtist naming tag. One of these days I'll look at fixing it, but no promises. If anyone who knows the code but doesn't have time wants to give some pointers where to look to fix, that'd help greatly. Edit: Some notes/findings: AudioTag.cs:572 ``` var artist = tag.AlbumArtists?.FirstOrDefault(); // This could be a problem if (artist.IsNullOrWhiteSpace()) { artist = tag.Performers?.FirstOrDefault(); // This could be a problem } ``` And the related class it's filling. Since it only allows a single artist. Maybe this just needs to be the full string, maybe it needs to be an array. MusicBrainz does define different separators though as well--Where album artists are created by joining on '/', that might not be most correct where MusicBrainz defines '&' or 'feat.' etc. Also a couple more notes/questions: In TrackFile.cs ``` // These are queried from the database public LazyLoaded<List<Track>> Tracks { get; set; } public LazyLoaded<Artist> Artist { get; set; } // This seems like it should be plural but the Track in Tracks should also? where should it be plural? Probably just in the Track object.. what is this? Album artist? But that's stored in the Album public LazyLoaded<Album> Album { get; set; } ``` In Track.cs ``` public int ArtistMetadataId { get; set; } // This needs to be plural ... [MemberwiseEqualityIgnore] public LazyLoaded<ArtistMetadata> ArtistMetadata { get; set; } // This should also be plural ``` Track.cs is where it really seems like the multi-artist stuff should be, to me. But this is just a first look. It's probably also where the joiners should be stored. But that's a more complex mapping, as it's given by MusicBrainz as "Artist" [ + "joinphrase" + "Artist" ]* For example, https://musicbrainz.org/ws/2/recording/40d5e635-ed5f-478a-9deb-8b30d752bea6?fmt=json&inc=artists has 3 artists, joined by "feat." and "&" There's a number of spots where Lidarr is deleting information. For example, on the track https://musicbrainz.org/release/3cd2afee-1aca-4374-88b8-9aeef4317d90/disc/1#7f43cf9c-6ca6-40ef-ad6f-2d44dc7cf723 ![image](https://user-images.githubusercontent.com/677609/161884520-c0b43e1a-1c0e-4cb9-9c10-556259939671.png) Note that it didn't touch Artists, Artist Sort order; while it did remove information from Artist (text including feat. etc.). It's got better information for Date, Genre. Also of note/related to the ticket, MusicBrainz Artist Id should include all track artists' IDs. **An open question:** Do we need to record the "joinphrase" for artists on the track, or can we assume A "feat." B [comma] C ... [ampersand] Z? My hunch is we can't assume, as it could also be "A & B" as a duet, not featuring. As a corollary, record label should include all labels. Some other info on inconsistencies: (After applying Picard's changes, excluding Date and Genre) ![image](https://user-images.githubusercontent.com/677609/161889015-0c97d8d2-e283-4b5e-8a53-efb9d4fb47ea.png) Note repeated tags, but also inconsistency with dates. The YEAR tag should not include -01-01 (useless information) that Lidarr is adding. And ORIGINALYEAR and ORIGYEAR values are swapped by Lidarr. Picard uses the longer tag name for a release year value, and the shorter tag name for the release date with month and day, while Lidarr does the reverse. I know the spec is not super specific about this, but for a fully automated system, it should match Picard IMO. As far as work that needs to be done, Track objects (database etc.) need to include all artist IDs, and either joinphrases or a text representation for filling out ARTIST. Joinphrases would be less data to store, as we can store IDs and fetch name/sort/etc. as needed. Corrolary multiple mappings would be good to change as well, since it's a similar operation. All I'm seeing there right now is PUBLISHER (Record Label). There's also some missing tagging RE Artists and Artist Sort Order that Lidarr could/should be setting. For now as a workaround, everything needs to be handled in MusicBrainz Picard. It appears that Lidarr is using flawed artist processing for the TrackArtistName field as well: so renaming is broken in Lidarr too.

deekerman commented

2026-02-20 01:12:22 -05:00

Author

Owner

@Kolbasz12 commented on GitHub (Nov 29, 2022):

I wish we could take some of the "smarts" from Beets and implement it into Lidarr for the way it handles tagging.

feat artists
continuous track numbers vs disc folders.

@Kolbasz12 commented on GitHub (Nov 29, 2022): I wish we could take some of the "smarts" from Beets and implement it into Lidarr for the way it handles tagging. 1. feat artists 2. continuous track numbers vs disc folders.

deekerman commented

2026-02-20 01:12:23 -05:00

Author

Owner

@FinalDoom commented on GitHub (Nov 29, 2022):

Probably worth a separate issue/feature request for porting over beets logic. This one's pretty specific.

On that separate idea, my thoughts:
I wonder if a less work-intensive solution could be something like:

Add a configuration item for script or webhook to kick off
Instructions for people to set up beets or something else.. docker container.. ??

My current workflow just has music dumped in a folder for review/fixing through Picard before ultimate library import. I'll have to check out beets though.

Maybe since beets is opensource though enough logic could be ported from it to be worthwhile.

@FinalDoom commented on GitHub (Nov 29, 2022): Probably worth a separate issue/feature request for porting over beets logic. This one's pretty specific. On that separate idea, my thoughts: I wonder if a less work-intensive solution could be something like: * Add a configuration item for script or webhook to kick off * Instructions for people to set up beets or something else.. docker container.. ?? My current workflow just has music dumped in a folder for review/fixing through Picard before ultimate library import. I'll have to check out beets though. Maybe since beets is opensource though enough logic could be ported from it to be worthwhile.

deekerman commented

2026-02-20 01:12:23 -05:00

Author

Owner

@grasshide commented on GitHub (Dec 9, 2023):

+1 for this issue.
Lidarr's feat removal of feat artists from songtitles makes it impossible for me to find songs related to an artist in any search.

@grasshide commented on GitHub (Dec 9, 2023): +1 for this issue. Lidarr's feat removal of feat artists from songtitles makes it impossible for me to find songs related to an artist in any search.

deekerman commented

2026-02-20 01:12:23 -05:00

Author

Owner

@Coder84619 commented on GitHub (Feb 18, 2024):

+1 any update?

@Coder84619 commented on GitHub (Feb 18, 2024): +1 any update?

deekerman commented

2026-02-20 01:12:23 -05:00

Author

Owner

@pozineg commented on GitHub (Dec 8, 2024):

...same problem with featuring artists metadata tags missing. Shame it hasn't been addressed for such a long time. Can you talented guys look into it, please.

@pozineg commented on GitHub (Dec 8, 2024): ...same problem with featuring artists metadata tags missing. Shame it hasn't been addressed for such a long time. Can you talented guys look into it, please.

deekerman commented

2026-02-20 01:12:23 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Dec 8, 2024):

The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one-ish active developer contributing to these projects, with none of the contributors working on them full-time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations.

As a result, the list of tasks to be completed across these projects, along with the various backends and modules, is extensive, while the available time for addressing these tasks is limited.

@bakerboy448 commented on GitHub (Dec 8, 2024): The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one-ish active developer contributing to these projects, with none of the contributors working on them full-time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations. As a result, the list of tasks to be completed across these projects, along with the various backends and modules, is extensive, while the available time for addressing these tasks is limited.

deekerman commented

2026-02-20 01:12:23 -05:00

Author

Owner

@thekiefs commented on GitHub (Feb 23, 2025):

This is similar to https://github.com/lidarr/Lidarr/issues/681, where we needed diverged rename logic based on the type of album. Perhaps it makes sense to implement something like MusicBrainz, where they have a scripting language meant to cover all rename possibilities.

For now, I've completely disabled Lidarr tagging and renaming, and will use MusicBrainz Picard (...even better if Lidarr integrated direct with Picard).

@thekiefs commented on GitHub (Feb 23, 2025): This is similar to https://github.com/lidarr/Lidarr/issues/681, where we needed diverged rename logic based on the type of album. Perhaps it makes sense to implement something like MusicBrainz, where they have a scripting language meant to cover all rename possibilities. <img width="992" alt="Image" src="https://github.com/user-attachments/assets/25aab6e1-ea3b-4df3-9f96-560ed3195ee2" /> For now, I've completely disabled Lidarr tagging and renaming, and will use MusicBrainz Picard (...even better if Lidarr integrated direct with Picard).