Because DBpedia seems to be down (it's responding very slowly with errors),
this seems like a good defensive action. It narrows the default sources to
those that resolve quickly, with only a couple of HTTP requests. We can
re-enable this again in the future if things seem to stabilize over at
DBpedia.
Rather than the ad-hoc one on library classes. This also avoids some confusing
duplication in the `beet fields` output, at the cost of turning off the plugin
distinction.
`LOWER()` implicitly converted numerical columns to strings,
causing the ordering of ['1', '10', '2'] to be correct.
The type of the column is now checked in the sql query
using `CASE WHEN..` construct. This ensures the column is
only `LOWER()`'d when dealing with TEXT or BLOB.
- Add a test to check for the track number behavior
- Add changelog entry
Fix#1511
Artists with non-typical casing (e.g., alt-J, dEUS) would not get matched on
DBPedia, as the RDFS:label uses arbitrary casing, and SPARQL provides only exact
matches. The FOAF:name attribute is always title-cased (e.g., Alt-J, Deus).
Due to a bug in DBPedia, the cover filename is truncated when it contains
parentheses, (e.g., 'Foo bar (band).jpg' gets truncated to 'Foo bar .jpg').
To work around this, an additional Wikipedia call gets made for all its
images, in which we try to match our truncated image.
The Wikipedia art source now catches the correct exceptions, instead of
a broad catch-all.
Wikipedia album images can be gifs, so these are now added to the list of
accepted content types.
The `enforce_ratio` and `minwidth` options depend on PIL or ImageMagick.
Previously it silently fails. Now it will log a warning, and accept the
image.
Tests concerning these options are skipped when no imaging backend is available.
Fix#1460
