But I notice some entries don’t have anything for “secondary-type”, for example:
{
"first-release-date": "1978",
"disambiguation": "",
"primary-type-id": "f529b476-6e62-324f-b0aa-1f3e33d313fc",
"primary-type": "Album",
"secondary-types": [],
"title": "All We Need’s a Hit",
"id": "bc68ceea-7838-4c1d-8cc0-920ca1dc55d9",
"secondary-type-ids": []
}
How is it that the musicbrainz page in the screenshot above filters out albums like this, but I don’t have any criterion in the returned JSON that I can use to do the same ?
The criterion is specifically “secondary types is blank” - if they had a secondary type, they’d be put elsewhere in the MusicBrainz display as well If something that should be live, compilation or whatnot has no secondary types, then that’s not an API issue, but an error with the MusicBrainz data (feel free to submit an edit to improve it!).
If you look at the musicbrainz page I am talking about, you will see, for example, that “All We Needs a Hit” does not appear in the list of albums even though in the JSON returned it does not seem to have any fields that would distinguish it from the albums in the list.
Which makes me think that there must be some sort of additional data in the database that is not being included as part of the returned JSON.
This case is a bit tricky to handle in the API I think.
This specific release group is not shown because the only release in it is a bootleg. So to fix this you’d need to query the releases, filter them for unwanted releases (bootleg, demo, promotional?) and only include the release group if it has wanted releases.
Thanks for the explanation for this. It will probably be a few days before I have a chance to take a look at the returned JSON again. Will let you know if I was able to work around the issue.
The status=official option only works with the “release” end point, but by including “inc=release-groups” I was able to filter the data on secondary-types.