Certain Albums not scrobbling

For example, I have SCARING THE HOES and The 2nd Amendment which is tagged with Picard. And using strawberry, It doesn’t change / show up on the listening now section.

The pattern here seems to be that albums with multiple artists just break whatever listenbrainz is trying to do.

1 Like

welcome to the party, Lemons~

I’m not too familiar with Strawberry, but my first thought is it might be an issue with the plugin/application, not with ListenBrainz… are the listens not getting submitted at all, or are they just not linked to a recording?

if it’s the latter, you can manually link a listen to a recording, just hit the three dots on the listen in question, hit “Link with MusicBrainz”, and paste the URL. once it’s been linked once, it should automagically link all other listens to the same track, past and future~

It’s not strawberry at fault. Used listenbrainz plugin in quodlibet and that says that these albums fail in submission. Only scrobbling through pano on my phone submits scrobbles but aren’t connected to albums. Connected to the recordings though, so I can’t link it.

that’s interesting… I’ve been using MusicBee and Simple Last.fm Scrobbler and haven’t noticed any issues, which is why I thought that…

are you on Linux? I’ll see if I can get @Victini or some others in here, as they might possibly be more knowledgeable than I on that front…

I’ve been noticing this too from SLS… I think the ability to correct which album is connected is/was being worked on? I remember seeing that somewhere…

1 Like

Scrobbling through VLC has the same result as my phone. It gets the details of the track, but it’s not connected to any album in specific, with no album cover. Checked the metadata again and it does have the proper tag for the album id. And yes i am on linux.

Now the 2nd Amendment scrobbles properly. Only SCARING THE HOES is giving me issues. I’d say this is a listenbrainz issue now.
EDIT: for some reason the 2nd amendment is tied to the wrong release while having the correct metadata

It’s probably something in the submission data that ListenBrainz doesn’t like, thus erroring out. I have a similar issue with failed submissions and I think it happens if the album artist tag isn’t present. I might try to debug that…

As for being tied to the wrong release, that’s probably a byproduct of the matching system LB has. It can match to recordings pretty well, but releases aren’t matched at all right now.

It’s strange since everything looks good in Picard. All tags are there, including Album Artist and MB_ALBUMID or something along those lines.

It has a tag to match to releases, so that shouldn’t be an issue.

Has this been reported to Strawberry? Is there any specific error message?

I’m having an issue with SCARING THE HOES as well, it isn’t showing up in my ‘Top Albums of Last Month’ section, but the individual tracks are showing up correctly
https://listenbrainz.org/user/Coloradohusky/stats/?range=month

@lemons_gothic I have a suspicion what’s happening. It’s related to tracks with more than one artist. I assume you have MP3 files and have tagged them with Picard using the default settings of using ID3v2.3.

Picard stores the artist MBIDs for each artist inside the files. Because there are multiple artists involved here there is more than one artist MBID (in this case c42e60f4-4520-4954-b6e4-82bbdf532c11 and 2371f42f-6646-4f19-ad73-70da1a5a6d2d for most tracks). But ID3 v2.3 does not properly support multiple values per track. So Picard stores those using a separator, by default a slash. So what it actually stores is a single value c42e60f4-4520-4954-b6e4-82bbdf532c11/2371f42f-6646-4f19-ad73-70da1a5a6d2d. When reading the data this should be splitted again.

Now Strawberry does submit the artist IDs when submitting to ListenBrainz. But because there is only a single value here and Strawberry does not split it it submits invalid data and the submission fails.

Try tagging your files in Picard with ID3 v2.4 instead and submission should work.

There are a couple of things that could be done to fix this:

  1. Strawberry could implement splitting values for ID3 v2.3
  2. Strawberry could validate whether the data inside the tag is a syntactically correct MBID and omit it if it isn’t
  3. ListenBrainz could ignore invalid non-mandatory data and just ignore it. @lucifer , what’s your opinion here?

UPDATE:

  1. And Picard could finally switch to ID3v2.4 by default. We had our reasons not to do this in the past, but I think it’s finally time
5 Likes

I actually recently reported this to strawberry: Send MusicBrainz IDs in ListenBrainz submissions | Strawberry Music Player Forum, where, as @outsidecontext guessed, the issue was multi-value support. Strawberry has since fixed this by splitting mbids on /.

Just happened to stumble onto this thread from the id3v2.4 pr. I did not realize that picard was still using v2.3 - switching to 2.4 is a very welcome change.

2 Likes

I’ve been battling this for a while and happened across this thread. One of the albums in question is:

This release has multiple release artists. In a raw dump from mediainfo in XML mode, I got the below, where album artists are separated by space-slash-space.

<MusicBrainz_Album_Release_Country>GB</MusicBrainz_Album_Release_Country>
<MusicBrainz_Album_Type>album</MusicBrainz_Album_Type>
<MusicBrainz_Album_Status>official</MusicBrainz_Album_Status>
<MusicBrainz_Release_Track_Id>68bd2966-27e8-4bf9-a180-0356e640e4f7</MusicBrainz_Release_Track_Id>
<MusicBrainz_Track_Id>8db2960b-06d4-4971-bf52-fcf38db77158</MusicBrainz_Track_Id>
<MusicBrainz_Artist_Id>9ddd7abc-9e1b-471d-8031-583bc6bc8be9</MusicBrainz_Artist_Id>
<MusicBrainz_Album_Id>c595ce53-eba3-46b4-b1b4-3b25a0014614</MusicBrainz_Album_Id>
<MusicBrainz_Release_Group_Id>eda1d1cc-ad90-4e80-aa04-32659f52bd8e</MusicBrainz_Release_Group_Id>
<MusicBrainz_Album_Artist_Id>9ddd7abc-9e1b-471d-8031-583bc6bc8be9 / 67e5938c-3953-4dfe-9d63-860bef0d8475 / c6dc626c-3122-4255-a8f4-8a7835d0476d</MusicBrainz_Album_Artist_Id>

Although Strawberry is supposed to split on slash now (I have 1.0.22), it may not be trimming the space from either side of the slash.

I started this journey on Picard 2.7 where ID3 was on its default 2.3. I made the following changes and got the same thing each time. To ensure that I knew the file had been saved in the new format, I kept reversing the positions of the first two album artists.

  • Switch to ID3 2.4.
  • Switch back to ID3 2.3 and change the separator from slash to semicolon. The tracks were still written out space-slash-space.
  • Switch the separator from semicolon to space-slash-space.
  • Switch the separator back to plain slash.
  • Switch back to ID3 2.4.

At this point I figured I had exhausted possibilities for the Picard I had, so I upgraded it (in the process dropping the old Ubuntu apt version and replacing it with flatpak). This put me at Picard 2.10, which had ID3 2.4 as the default. It cheerfully wrote out space-slash-space delimited MBIDs in a single XML tag, just like Picard 2.7.

It would take a while to acquire a different tag editor to remove the spaces and see if Strawberry can send those to Listenbrainz. I figured I’d ask if there’s some obvious reason why Picard is ignoring everything. Is there some other switch I didn’t see in Options?