Proposed enhancement - config item to stop or retry when musicbrainz is not available.

[pccasto]

I've hit several instances recently where musicbrainz is not available.
I'd rather not have a CD encoded as unknown and have to go back and do manual fix-ups later.

I'd propose adding in a config item to either set a fixed number of retries, or a flag to fail if musicbrainz is not accessible.
Along with the corresponding logic in the code...

Default would be current handling, with a message to let users know of the new config item so they could add it if desired.

I'm also thinking about a flag to skip when musicbrainz is available, but has no info.
Use case there is for non interactive ripping - insert CD, walk away... save the ones that need interactive for a session later, after creating the artist/track info and uploading it.

Are these changes you'd be open to?

I haven't started on this effort yet, but seems fairly doable -- adding to the spaghetti :-)

Quite the extensive refactor work you've defined for this project!

[poddmo]

I've also had the "musicbrainz not available" issue. I don't know how much time or retries would have been necessary to restore access. Having generic metadata_retry options would be best but there are many types of pasta.

I workaround by having CDDB as a fallback metadata source.
In over 2000 CD's ripped with abcde, I never use automated. I want accurate metadata and have had bad track titles early on when I didn't pay attention. I always:

• diff at least the first two results
• edit the selected entry to:
  • standardise the artist names with my existing collection or as per discogs ANV
  • set the year to the original release year, copy and paste the genre from discogs
  • add comments to EXTD and EXTTN fields
    I still have another ~1000 I care less about that I'm considering running non-interactively. But just can't bring myself to do it. I have to handle every disc individually anyhow to add it to my collection on discogs first. Once I know the exact release and the context of master release, I can't help but do the encoding interactively.

But I do care that automation works sanely and agree with your proposals.

Off the top of my head without looking at the code::
For the case when musicbrainz has no info, if we are non-interactive then a config item could skip. not sure how to handle clean-up or informing the user in a useful way.
Because I run interactively, I get the musicbrainz submit URL, paste that into my browser and edit the musicbrainz release (Usually just means adding CD TOC to existing release).

For the unreachable case a musicbrainz specific retries
Example config variables:
MUSICBRAINZ_WAIT = sleep in seconds between retries
MUSICBRAINZ_FAIL

• 0 = no change in behaviour from current - this is default
• -1 = retry indefinitely, wait between tries. Not recommended. What do musicbrainz API rate limits say?
• =>1 = retry 1 or more times, wait between tries

[pccasto]

I'll put together a proposal / pull request- expect early next week. Yes - the default will be do no harm - no change to the existing handling. I'll have a need for this, even if it doesn't make into the main line (and I certainly won't second guess any decision you might make in that regard!).

I'm coming at this from an automate as much as possible & correct later if I see something that is too far out of whack. I expect most will be close enough that I won't notice if titles have incorrect capitalization or some other data entry issue from one of the dbs. I've ripped most of my collection over the years, using a variety of tools, but have several hundred that need some attention. many of those are oddball that might not be in a db. My thought is push in drive, walk away, do other things. Home notification system tells me when it's done, or errors. Or if I simply see the drive popped open, I pop in another.

[vdubgeek]

I experience Musicbrainz timeouts on a pretty regular basis. Having retries configurable via command line or config file arguments would be a welcome enhancement.