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.
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
- Minimum image width can be specified via minwidth (default `0`)
- The image ratio can be enforced to 1:1 using `enforce_ratio` (default `no`)
See #1058
I like the CAA as a first-priority search because the images are generally
high-quality and there's no metadata ambiguity (we always find the right
release if it's in the catalog).
Add a configuration section that lists all options for each plugin.
List options in alphabetic order.
Mention the default value for each option.
Use same sentences to describe concepts common to different plugins eg 'auto
option, install description
Reading the fetchart docs it was not clear to me that it would use _any_
image file found alongside your music files, even if the image file did
not have one of the five privileged names (cover, front, art, album,
folder). I humbly propose these edits to the docs in an attempt to make
it more clear that, by default, any local image file will be used.
I also corrected '"album," _for_ "folder"' to '"album," _or_ "folder"',
and from reading the code I'm pretty sure that remote_priority needs to
be true, not false, in order to prefer remote sources.
We currently just document the fact that convert.exe can interfere with finding
ImageMagick's convert binary. We can solve this with a config option easily once
confit is merged.
This also changes the line endings for fetchart.rst back to Unix.
`urllib.urlretrieve` was using the correct extension in most cases -- I think
when the URL ended with .jpg -- but not in every case. This was leading to files
named just "cover" and not "cover.jpg" or something else sensible. In
particular, proxied URLs don't have .jpg extensions. This generates the filename
manually so the source image always has an extension.
artresizer.py instances an ArtResizer object that uses internally the PIL; ImageMagick
or a web proxy service to perform the resizing operations.
Because embedart works on input images located on filesystem it requires PIL or ImageMagick, whereas
fetchart is able to do the job with the fallback webproxy resizer.
This necessitated a slight refactoring in the plugin event handling mechanism.
Rather than loading all handlers up front and storing them in a module-scope
structure, we now scan for event handlers at every send(). This is probably
very slightly less efficient but allows for more flexible logic.
