Web service as not to showing ASIN relation for some albums

IMHO the ASIN identifier you're looking after is deprecated.

You should use 'url-rels' instead in your request: for example http://musicbrainz.org/ws/1/release/2a12f877-2b42-48f8-bbea-af51dd208c0e?type=xml&inc=artist+url-rels (note the "+url-rels" I added).

It returns all url relations (Amazon, Discogs, Wikipedia, ...). If you only want ASIN, pick relations with type = "AmazonAsin".

I'm finding this problem in PicardQT... are the requests there badly formed? Is there anything I need to do to get it to work better?

#2539 is a duplicate of this

This problem had nothing to do with the web service -- for some reason some ASINs are not getting pushed into the album_amazon_asin table. I'm not sure if this problem still exists after I heavily mucked with all the coverart stuff. I'll run the script after the release and then we'll see if we get more of these cases reappear.

If you see them reappearing after the next release, please reopen this bug.

zdzisio@poczta.xz.pl: I forgot to add, thanks for the great bug report. Your example let me pinpoing the problem instantly. Thanks!

Here is one more case:

http://musicbrainz.org/release/f52dd070-00d3-4882-9df0-e456c8a6afa3.html http://musicbrainz.org/ws/1/release/f52dd070-00d3-4882-9df0-e456c8a6afa3?type=xml&inc=artist+counts+release-events+discs+trackshttp://musicbrainz.org/show/edit/?editid=6682365 http://musicbrainz.org/show/edit/?editid=6682365

#2855 is a duplicate of this

luks: Found another variety of this. This one does get ASIN from the feed (unlike most of the others, where QT reads %asin% as null), but the plugin doesn't load art: http://musicbrainz.org/album/a7ccb022-f437-4492-8eee-8f85d85cdb96.html?tport=8000

Yay, my favorite bug is in fact not fixed. Yaaaaaay!

I'm using QT to help track down missing info in the database. Currently, I'm using a $if($and(%asin%,$eq(%releasestatus%,official)) filter to sort official releases w/o ASINs to one place, while placing all other releases to another. In the process, I'm slowly finding 2 groups with ASINs problems like this -

1) Those with an ASIN that for whatever reason isn't being passed on to QT (and thus, they end up in the no-ASIN grouping)

2) Those with an ASIN (which does have art at AZN) that does pass on to QT (ie, goes into the has-ASIN directory), but for which the cover plugin isn't downloading any art.

It's going to take a bit of time to re-process all the files, but once I've finished, would it be useful in tracking down this bug for me to post a list of the releases found to fall into each group?

(Also, it'd be nice, now that we have access to non-AZN coverart (thanks aCiD2 and luks!) if I could do a similar sort using, say %coverart% - a "has either ASIN or coverart" and a "has neither" grouping.

Replying to BrianFreud:

1) Those with an ASIN that for whatever reason isn't being passed on to QT (and thus, they end up in the no-ASIN grouping)

These are the problematic ones.

2) Those with an ASIN (which does have art at AZN) that does pass on to QT (ie, goes into the has-ASIN directory), but for which the cover plugin isn't downloading any art.

This a bug/missing feature in the plugin (the images are in non-standard location). Not related to the server bug.

Found another one: http://musicbrainz.org/album/5c07b64a-1d67-4098-b081-5f17330416d4.html?tport=8000

Since I ran the ASIN cleanup script, these problems have finally been taken care of.