Many commands and plugins use `item.write()` to update tags. Since the success
of the call is not critical to the functionality of most consumers we want to
catch any exceptions, log an error and continue with our task. The new method
encapsulates this logic.
This fixes#675.
As outlined in #299, we broke many places in the code that were expecting
_album_for_id and _track_for_id to return a single item rather than a list. I
took this opportunity to divide up the interface: there's now one function for
MBIDs (returning a single object or None) and one for generic IDs (returning a
list).
It's possible that these plugins might require a little more thought
into how they should work (or not work) with potentially multiple albums
matching an idea, and potentially those those albums being an incorrect
match (e.g. if two data source plugins share a simple numerical ID
format).
As _print_and_apply_changes itself does for items, we now shortcut
modifications (metadata and filesystem) for albums when no changes are
required for a given album. This avoids effectively doing a "beet move" on an
album even when nothing has changed.
This change uses _album_for_id and _track_for_id instead of the full
autotag.match.* functions. This should be faster (requiring fewer calls to the
MusicBrainz API) while also being more predictable. It also won't, for
example, use acoustic fingerprinting even if the chroma plugin is installed.
Finally, this change catches the error case in which MBIDs are erroneous. This
can happen, for example, if the user has some track MBIDs left over from
before the NGS transition.
The main change here is to use shorter transactions -- one per matching entity
-- rather than one large one. This avoids very long transactions when the
network happens to move slowly.
this plugin provides a faster way to query new metadata from
musicbrainz. (instead of having to 're-import' the files)
Currently it lacks all forms of documentation and will only work for
album queries. not really tested so far so be careful
