I'm using Access AcousticBrainz to get the BPM if empty. It works great if the AcousticBrainz entry has a BPM field. Sometimes, though, I'll get a 404 error.

For example, this recording: http://musicbrainz.org/recording/a2758e35-610a-4ac8-b87b-3e2f86920cbc an AcoustID 4d10d202-121f-4caf-aac4-21391eaa32b2 http://acoustid.org/track/4d10d202-121f-4caf-aac4-21391eaa32b2, which is somehow linked to 2 MusicBrainz recordings.

How can I handle this in the Action?

I saw the Test function, but couldn't exactly figure it out after reading the documentation.

Check your email for a prerelease patch.

Far too many networking errors and how they propagate is a pain. A few weeks ago there was a panic when one of the online data sources' servers were passing 'zero results' for everything as opposed to indicating a 'down' condition.

Indeed it is. Lots of 503 errors. Still, they do a pretty amazing job considering it's a non-profit and all.

So does the checkbox for "ignore errors" apply to 404s and 503?

The 404 just means there isn't something to pull from to populate BPM and Key. From what I've read / heard, it's relatively new capability, and not all files have them. So with a 404 error, you could re-run it as many times as you wanted and would get the same result (until someone populated the database with the info). So, IMHO, it's not really an "error" per se, especially if the documentation mentions it might not be available for every song.

A 503 error (or whatever) could be a lot of things, and it would be good to know it's something to try again, just not right now.

So while I (rather, most people, I'm guessing) wouldn't care about the specifics of the error, they might care if it was a temporary one or not.

The way the patch is implemented is that all network errors are ignored. The "ignore errors" option simply suppresses an error message. I recently implemented the ability to detect 503s on MusicBrainz accesses. Even though Yate is extremely strict about the rate limiting rules there are still situations outside our control which result in a 503. For instance, they might temporarily refuse requests from a particular IP address.

I need a better and more general solution to make the network response codes available for all networking statements. However some commands (such as Access AcousticBrainz) issue multiple requests when operating in stepwise execution mode. For example let's say you issue an Access AcousticBrainz on 10 files and one returns a 503. There is no easy way to associate the response code with the offender. 🙁 I'd have to set a UDTI such as '503' or 'AcousticBrainz 503' or something....and that would get preserved if you saved the file. Most users don't like unexpected metadata.