This reflects the `try_write` approach will handles write failures
elegantly, by logging the error and continuing. We do the same with
`move`, `art_set` and `move_art`.
We also handle exceptions on `before_item_moved` and `art_set` plugins
hooks, the latter of which is moved *before* the file operations to
remain consistent with other hook configurations.
That might be a mistake and API-breaking change, another approach
would be to have a new `before_art_set` hook instead.
We also introduce a new hook (`move_art`) for those operations as
well.
The point of this patch is to make it possible for plugins to send a
signal (through the already FileOperationError exception) to callers
that it should skip a specific item or artwork.
This is essential to allow beets to better integrate with other
utilities like bittorrent clients which may rewrite those files. The
rationale here is that some music collections will have *parts* of
them managed by such clients in which case we should be careful not to
overwrite or move those files.
Operations like copy or hardlink are not handled by this, for that
reason. We may also want to do proper error handling for those as
well, that said, but that seems out of scope for this specific
issue (#2617).
- Clarify basic search behaviour in intro chapter of discogs plugin,
- and state change introduced in PR#4227 (discogs: Discogs query on
insufficiently tagged files)
- When files are missing both, album and artist tags, the Discogs metadata
plugin sends empty information to the Discogs API which returns arbitrary
query results.
- This patch catches this case and states it in beets import verbose output.
When the delete_originals was set, beets would print the following, regardless
of the presence of the quiet parameter:
convert: Removing original file /path/to/file.ext
This commit ensures that the log is only printed when quiet is not present.
The routing map translator `QueryConverter` was misconfigured:
* decoding (parsing a path): splitting with "/" as tokenizer
* encoding (translating back to a path): joining items with "," as separator
This caused queries containing more than one condition (separated by a
slash) to return an empty result. Queries with only a single condition
were not affected.
Instead the encoding should have used the same delimiter (the slash) for the
backward conversion.
How to reproduce:
* query: `/album/query/albumartist::%5Efoo%24/original_year%2B/year%2B/album%2B`
* resulting content in parsed argument `queries` in the `album_query` function:
* previous (wrong): `['albumartist::^foo$,original_year+,year+,album+']`
* new (correct): `['albumartist::^foo$', 'original_year+', 'year+', 'album+']`
This is mostly "defensive programming": clients *should* only call this
on bytestring paths, but just in case this gets called on a Unicode
string path, we should now not crash.
Fixes#4168. Also closes#4192, which it supersedes.
The original problem is that this implementation used bytestrings
incorrectly to invoke `mktemp`. However, `mktemp` is deprecated, so this
PR just avoids it altogether. Fortunately, the non-deprecated APIs in
`tempfile` support all-bytes arguments.
