mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Jellyfin 10.10.x (and 10.11.0-rc4) not splitting audio artists containing "feat." into multiple artists #7236
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @verybadsoldier on GitHub (Aug 10, 2025).
Description of the bug
On Jellyfin 10.10.x, when creating a music library, an artist tag containing "feat." is not split up anymore into multiple artists.
I tested in on 10.10.0, 10.11.0-rc4 and on 10.10.7 on Windows and 10.10.7 on Linux.
I just installed 10.9.11 for testing, and it works fine there. So, it seems to be a regression in 10.10x. I could not find it mentioned in the release notes, so I assume it is not a intended change.
Reproduction steps
What is the current bug behavior?
Only one artist called "Eminem feat. His Mother" has been created.
What is the expected correct behavior?
There should be two artists: "Eminem" and "His Mother".
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.10.7
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@gammaandromedae commented on GitHub (Aug 14, 2025):
Can confirm this is an issue on my Docker deployment on Ubuntu 24.04. If the files' metadata is changed to "Eminem\His Mother" manually, Jellyfin picks it up as two artists for certain file types (it seems to work on FLAC files, but not mp3s, getting a character encoding issue of some sort) but you lose the "feat." context as opposed to a more general collaboration.
@verybadsoldier commented on GitHub (Aug 15, 2025):
I made a small adaption to 10.10.7 to bring back artist parsing behavior from 10.9.x:
https://github.com/verybadsoldier/jellyfin/tree/dev_music_artist_behavior_10.9-vbs
Not sure about all consequences this would have, but it seems to work so far.
@gnattu commented on GitHub (Aug 17, 2025):
Unfortunately this is a "designed to break" case with our new metadata parser.
Jellyfin is moving to encourage standardized tags for multi-value metadata fields, instead of using heuristics to "guess" from a single value tag. Both the Vorbis tag (also used by FLAC) and the ID3v2.4 supports native multi-value tags, which is now the default way Jellyfin probes. For backwards compatibility, we also introduced a fallback option so that you can use a single character as a custom delimiter: https://github.com/jellyfin/jellyfin/pull/12385, but unfortunately that won't support "feat" as a separator because now the delimiter is limited to only support one single character.
@verybadsoldier What your change did was just reverting to the now deprecated fallback prober which still does heuristics based tag splitting. That one is not going to be maintained anymore and that could be wrong in the future. But if it works for you, you can keep using that one.
@MinmoTech commented on GitHub (Aug 17, 2025):
@gnattu Does "moving to" imply that multi-artist tags were already supported in 10.10.6?
As an example, I have an album with this metadata (tagged using beets, but musicbrainz picard would have given the same result):
Puddletag screenshot to show that it seems to indeed use multi-value fields correctly:
But the Jellyfin still only picks up albumartist/artist field.
Is the "best-practice" of how to tag music for jellyfin documented somewhere?
Edit:
This setting seems to have solved it on 10.11.x, on 10.10.x it only fixes the artist, but not the albumartist:
@verybadsoldier commented on GitHub (Aug 17, 2025):
Hm ok, I was afraid it could be intentional as you said. The problem is that some people are maintaining their music collections literally since decades, and having their files tagged in a certain way, using certain tools for tagging with specific features and limitations, using a certain workflow etc. So, having to re-tag everything to comply to the new guidelines might be a big hurdle for them. For me personally, I have no instant idea how I could do that for my files in a feasible way.
Giving users the chance to keep the old behavior by customizable separators (and artists whitelist) is a good way, in my opinion. The only problem I see is, that custom separators can only be single characters currently. Would it be possible to get those separators as strings, so people could get back the splitting on "feat." for example?
@sjorge commented on GitHub (Aug 17, 2025):
I struggled a lot to when migrating to jellyfin, MusicBrain Picard really helped. It can also pre-calculate album and track gain values with a plugin so jellyfin can just pick them up.
@davidscarth commented on GitHub (Aug 23, 2025):
i'm looking forward to being able to scan without 100000 artists because theres a "xyz ft. so and so". if for whatever reason this gets "fixed" please make it a toggle. i really just want primary artist and dont need tracks from an album being assigned to some made up nonsense separate of the rest of an album.
@devleesch001 commented on GitHub (Sep 17, 2025):
Can cofirme doest work for me too
But many ripped discs use this format, it may be historical but the majority of sources, even recently purchased discs still use this format, it is really necessary to be able to use a string as a separator, especially,
feat.featuring.I tend to agree with the idea that we can configure a list of strings as a sperator, the best would even be a regex, or a list of regex
@vitorfulgencio commented on GitHub (Sep 17, 2025):
Same issue here, it fills my Artist / Album artist list with mutliple entries of the same artist but featuring someone else.
Alesso Ft. Tove Lo
@MinmoTech commented on GitHub (Sep 17, 2025):
@devleesch001 @vitorfulgencio If your library is properly tagged with MusicBrainz Picard or beets, you can enable the "prefer ARTISTS tag if available" library setting, that would also fix the issue.
@devleesch001 commented on GitHub (Sep 17, 2025):
It doesn't seem to work for me, even after deleting all existing metadata and re-scanning the entire library, the album images are downloaded correctly, but I still have dozens of artists with a 'feat' inside.
For example:
However, I'm not sure if the songs were properly tagged with MusicBrainz, the options may be enabled.
@devleesch001 commented on GitHub (Sep 17, 2025):
I looked in the metadata manager, the artist folders are tagged, the albums are tagged but no sound is tagged, I imagine that Jellyfin applies the delimiters based on the metadata of the files
for exemple :
Path :
Georgio>Ciel enflammé - Sacré>Unique(default metadata artistGeorgio feat. Doums)Georgiotracked by MusicBrainz Artist Id : 4020ea18-d886-483c-910f-a0e7e039c097Ciel enflammé - Sacrétracked by MusicBrainz Album Id : ed6596d6-93cf-4082-b35e-146e7d3b63bcUniquenot tracked MusicBrainz Track Id is emptyBut
Uniquehave this MusicBrainz Track Id a0c54268-e139-4c4d-bbf2-c1d56df40cb0In view of this, there may be another bug, on the attribution of metadata ?
@radomnoob commented on GitHub (Sep 17, 2025):
Hi, I got the same bug, But I don't know that was a bug. So to fix that, I go in the "Custom Tag Delimiter" parameter I put ";" as delimiter and now when I add an album I edit the tag with mp3tag all the "feat" "featuring" "/" "&" "ft." etc.... was automatically replace by ";". That maybe not the perfect solution but I have more than 210 albums and 520 artists, and that work.
@devleesch001 commented on GitHub (Sep 19, 2025):
Oh ok, I didn't understand,
MusicBrainz Picardandbeetswas software. I use beets cli in my NAS and it's work pretty well, all my library is now fixed@jellyfin-bot commented on GitHub (Jan 18, 2026):
This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.
If you have any questions you can use one of several ways to contact us.
@verybadsoldier commented on GitHub (Jan 18, 2026):
Still an issue.