Tracks with multiple artists aren't scrobbled with multiple artists

[gbcox]

This is probably due to the fact (as I understand it) this plugin was branched from a lastfm plugin. AFAIK, Lastfm doesn't support scrobbling multiple artist per track, whereas Listenbrainz does. I've attached a screenshot from picard which shows the multiple track artists, plus the output from rescrobbled showing how the information is being successfully sent to listenbrainz and another screenshot from listenbrainz show the successful scrobble. Let me know if you need additional information.

Jul 03 13:10:52 charon systemd[1674]: Started rescrobbled.service - An MPRIS scrobbler. Jul 03 13:10:53 charon rescrobbled[35797]: Authenticated with ListenBrainz successfully! Jul 03 13:10:53 charon rescrobbled[35797]: Looking for an active MPRIS player... Jul 03 13:10:53 charon rescrobbled[35797]: Found active player Elisa Jul 03 13:10:53 charon rescrobbled[35797]: ---- Jul 03 13:10:53 charon rescrobbled[35797]: Now playing: Farruko feat. Ñengo Flow - Cucaracha (La 167) Jul 03 13:10:54 charon rescrobbled[35797]: Status updated on ListenBrainz successfully

[lyarenei]

Listenbrainz API does not specify format for artist name field if a track has multiple artists credited. The only requirement for now seems to be that the artist field must be a simple string. ~It's a bit strange since artist MBIDs are a list type, so there's no issue sending multiple MBIDs (and the plugin should do as well, as long as Jellyfin recognizes them correctly).~

I didn't (and don't) want to introduce a custom format for this case. Even if I did and went with semicolon for example, it would look weird and of course it still wouldn't reflect the format one would expect. So at this moment, the plugin just picks up the first artist Jellyfin has stored which is for the majority of the music out there a correct value anyway. Jellyfin also does not store Artist Sort Order in track metadata, so I can't use that either. According to your screenshot, it seems resclobbled uses the Artist Sort Order field primarily, rather then the Artists field.

The more I think about it the more I think the artist field in API specification is intended this way as it makes sense in case the artists are to be sent as the sort order string. In that case, the proper fix would be to update Jellyfin to work with the sort order tag. Then this plugin can be easily updated to use the new metadata field. Other than this, a quicker and probably easier option would be to modify the metadata locally (either in Jellyfin or in the music files directly).

[gbcox]

Thanks for the quick reply, I really appreciate it. Just seems odd that all the programs that I use which scrobble to Listenbrainz (qmmp, mpris-scrobbler, rescrobbled, Plex (using eavesdrop.fm), Tidal (using android Pano Scrobbler) do this with no issues. I'll check with the Listenbrainz people and see what they say. Something isn't adding up.

[lyarenei]

Well it just means that the various tools you mention do in some way use the artist sort name and the sourcing application provides it.

In the case of Jellyfin, it seems support for only a subset of musicbrainz tags was implemented (probably inherited from emby) - for example recording ID required by Listenbrainz is not stored either, this plugin makes additional requests to MusicBrainz to get it. Maybe the sort name could be acquired the same way as a workaround. That should be pretty easy to fetch it - I'll probably take a look into that.

[gbcox]

Thanks again for the quick reply. I submitted a ticket with Listenbrainz here: https://tickets.metabrainz.org/browse/LB-1115

They have recommendations on how to enter this information into the Musicbrainz database, so if they don't have a standardized way to scrobble this, they probably should. https://musicbrainz.org/doc/Artist_Credits

[lyarenei]

I've just released version 2.1.0.1 which has the changes from #11. As this is 2.x.y.z version, it is for Jellyfin 10.8.a.b. I'll update the version for Jellyfin 10.7.a.b later.

[gbcox]

Working perfect! Thanks so much for doing this!

[lyarenei]

I'll close this for now as the original issue is fixed now. Feel free to reopen this if there are any updates to address, thanks.

[MonkeyDo]

Hello! ListenBrainz developer here.

The listen JSON submission format was intentionally open-ended, but considering this is a pretty standard use case we could formalize the format. What we use for our Spotify importer (which provides the majority of listens in ListenBrainz at the moment) is the following:

The artist_name filed is, as you mentioned, a simple string representing all the artists on the track. I think the way you implemented that in #11 is actually a great way to go.

Furthermore, we provide an array of artist names and release artist names in track_metadata.additional_info for completion, which we are not currently using for representation on ListenBrainz (but that should come soon—we will make more metadata available on each listen)

An example:

{
    "track_metadata": {
        "artist_name": "Bad Bunny, Jowell & Randy, Ñengo Flow", // Spotify's representation of the artist string
        "release_name": "YHLQMDLG",
        "additional_info": {
            // omitted some fields
            "artist_names": [
                "Bad Bunny",
                "Jowell & Randy",
                "Ñengo Flow"
            ],
            "release_artist_name": "Bad Bunny",
            "release_artist_names": [
                "Bad Bunny"
            ],
        },
        "track_name": "Safaera",
    }
}

Does that seem reasonable to you?

[lyarenei]

Hi @MonkeyDo, thanks for the info. :)

The listen JSON submission format was intentionally open-ended, but considering this is a pretty standard use case we could formalize the format.

The artist_name filed is, as you mentioned, a simple string representing all the artists on the track. I think the way you implemented that in #11 is actually a great way to go.

Yeah, I understand this field cannot have a specific format. I think maybe just a small note in api docs would be enough - something along the lines like "despite the name of artist_name field, in case of multiple artists for a track, all artist names are expected here, preferably in a full artist credit string", maybe with an example or two.

Furthermore, we provide an array of artist names and release artist names in track_metadata.additional_info for completion, which we are not currently using for representation on ListenBrainz (but that should come soon—we will make more metadata available on each listen) ... Does that seem reasonable to you?

I thought that these look a bit redundant at first, since an application can sumbit just the artist MBIDs and let the server do its thing with them. But then not all aplications have MusicBrainz metadata available to submit, so yeah, it makes sense to have these fields available as as well.

But it looks like they are not documented? At least not at https://listenbrainz.readthedocs.io/en/production/dev/json/#json-doc. Or I guess the documentation will be updated once the metadata changes you are talking about will be deployed?