Fixes#1264: When a re-import triggers fetchart, the existing album art is no
longer resized if it already has the correct dimensions. This avoids creating
new album art files with unique filenames ("cover.n.jpg").
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.
requests/urllib3 is throwing an exception due to an internal problem triggered
by some sort of timeout. This change catches the TypeError so that beets
reports "error fetching art" instead of crashing when this happens.
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
Using -500 URLs for coverartarchive.org will only ever return images
where the biggest dimension is (width or height) is 500 pixels,
regardless of what fetchart settings are otherwise set.
This commit removes the -500 from the URL entirely rather than using it
conditionally, since a maxwidth of 500 will allow for a 600 high and 500
wide image, but CAA.org/...-500 would return a 500x417 image instead, so
not enforcing a size is the only way to ensure the user's {max,min}width
settings are properly respected.
- 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
E.g., `colorize('text_success', 'hello world')`
To ensure compatibility with 3rd party plugins, a valid color ('red') can still be passed,
but it will be logged.
- Colors are mapped on to a dictionary using abstract names (e.g., text_success)
- Add `colors` option under `ui` to allow users to choose their own color scheme
- Move configuration option `color` from top-level to `ui`
- Show deprecation warning if top-level `color` configuration is used (but respect it)
Fix#1238
Include import of __future__ features division, absolute_imports and
print_function everywhere. Don't add unicode_literals yet for it is
harder to convert.
Goal is smoothing the transition to python 3.
Breaking changes: plugins should set set _import_stages instead of
import_stages. From outside the latter is replaced by import_stages().
This is because it is now wrapped with log level-getting & -setting
statements.
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).
* Ensure that `config.as_str_seq()` returns a list of unicode objects.
* Map these to bytestring paths so we can compare them to other paths.
Fixes#887
This reverts commit c56412a1d5.
- The Requests library advertises itself as thread safe.
- Cookies aren't so interesting, but keep-alive /
connection pooling would be nice to have.
This might have been perfectly correct, but I read that requests.Session
objects share cookies between requests. That makes me nervous for two reasons:
- thread safety (does requests lock the cookie jar internally? who knows?!?)
- leaking cookies could have privacy/performance implications; we don't need
'em anyway
- Remove "part", "volume", "vol." multi-disc markers. These are often
part of album titles, and not necessarily indicative of a multi-disc
album. Only look for "CD X" and "disc X" (case insensitive), ignoring
white space and other non-word characters.
- Don't only expect each disc to be in a subdirectory of a common parent
directory, with all siblings belonging to the same release. Also match
any consecutive siblings (even when the parent contains other albums)
that are named with the same prefix and multi-disc marker.
- The `albums_in_dir(path)` function now always yields a list of paths
along with each list of items. `ItemTask.path` is now always a list of
paths.
- The `displayable_path(path)` function now accepts a list of paths, and
will join them with "; " by default. This can be changed with the
`separator` argument.
- The `sorted_walk()` function now does a case insensitive sort on
directories, but still returns case sensitive results. This allows
better multi-disc album detection.
- The `art_for_album()` function now takes a list of paths as its second
argument, instead of a single path.
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.
Searching for `convert` or PIL has non-negligible performance overhead, so it's
preferable to only do it when really necessary. This way, the search is only
performed when ArtResizer.shared is accessed for the first time.
An earlier commit broke the call to art_for_album here (too few arguments).
I've also now propagated the maxwidth setting for the command to match the
import hook.
Fixed a number of issues with the changes to fetchart:
- Remove redundant fetches. This was making the Amazon source download every
image twice even when art resizing was not enabled!
- Restore local_only switch in plugin hook, which got lost in the shuffle at
some point.
- Don't replace the original image file in-place; use a temporary file instead.
This would clobber the original source image on the filesystem with the
downscaled version!
The previous method was to change self.__class__ dynamically to make __init__
instantiate different classes. This new way, which uses bare functions instead
of separate functor-like classes, instead just forwards the resize() call to
a module-global implementation based on self.method.
Additionally, the semantics of ArtResizer have changed. Clients now *always*
call resize() and proxy_url(), regardless of method. The method makes *one* of
these a no-op. This way, clients need not manually inspect which method is
being used.
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.
