The MPD protocol allows batching commands. There are two choices for the
first message that announced a batch is starting, and we just go for the
one that causes the server to respond with a marker message between each
individual response, since that's easier. This might need to be tweaked
in order to test the behaviour with the other batch indicator.
MPD now supports more fields ("tags") than what BPD advertises. Fixing
this should be a simple task of extending the mapping of fields to tags
in BPD's implementation.
The current MPD spec is several versions ahead of BPD. These tests just
compare the full specified list of commands against what BPD claims to
support (without actually testing their implementations). It's handy as
a measure of progress against the specification, but can perhaps be
dropped later once all of the individual protocol methods have tests.
Fetch flexible attributes once for all items instead of once per
item. For queries with larger result sets this drastically cuts
down the number of issued sqlite queries.
The setting is quite confusing. After having difficulty getting the autotagger to accept an id for a specific release that I knew was correct, I investigated and count [this closed issue][0] that totally explains the problem.
To clarify the issue, I quoted Adrian from the issue and elaborated a bit, providing the solution. Unfortunately, the solution is undocumented. I'd like to document it, but I am unsure what the actual weighting system in `distance_weights` is. Adrian says 0.9 to ignore missing_tracks, which implies it's similar to the distance weighting in the other settings, but other settings in the default config are set to multiples of 1, implying it is not.
[0]: https://github.com/beetbox/beets/issues/3064
Probably fixes#3165. There were several things going wrong here:
1. For some reason, this was using the *filesystem* encoding, which is
what you use to decode filenames. But this was general command
output, not filenames.
2. Errors in decoding threw exceptions, even though all we do with this
output is show it to the user.
3. The prints were using `displayable_path`, even though the lines are
*already* Unicode strings.
Hopefully this cleans up that mess.
