PR #3748 changed the way cover art is fetched from the cover art
archive, but the manual addition of a `-` to the width suffix that was
needed when the image URI was being constructed manually was not
removed. Because of this the plugin would try to look up the property
under `thumbnails` that didn't exist (for example `-1200` instead of
`1200`), which would fail.
remove interlacing by default when resizing/down-scaling, the
`deinterlace` option is to remove interlace when otherwise no processing
would have happened.
Squashed from the PR, relevant commit messages follow below:
Added file size option to artresizer
- In line with comments on PR, adjusted the ArtResizer API to add
functionality to "resize to X bytes" through `max_filesize` arg
- Adjustment to changelog.rst to include max_filesize change to ArtResizer
and addition of new plugin.
Added explicit tests for PIL & Imagemagick Methods
- Checks new resizing functions do reduce the filesize of images
Expose max_filesize logic to fetchart plugin
- Add syspath escaping for OS cross compatibility
- Return smaller PIL image even if max filesize not reached.
- Test resize logic against known smaller filesize (//2)
- Pass integer (not float) quality argument to PIL
- Remove Pillow from dependencies
- Implement "max_filesize" fetchart option, including
logic to resize and rescale if maxwidth is also set.
Added tests & documentation for fetchart additions.
Tests now check that a target filesize is reached with a
higher initial quality (a difficult check to pass).
With a starting quality of 95% PIL takes 4 iterations to succeed
in lowering the example cover image to 90% its original size.
To cover all bases, the PIL loop has been changed to 5 iterations
in the worst case, and the documentation altered to reflect the
50% loss in quality this implies. This seems reasonable as users
concerned about performance would most likely be persuaded to
install ImageMagick, or remove the maximum filesize constraint.
The previous 30% figure was arbitrary.
* fetchart: Improve Cover Art Archive source.
Instead of blindly selecting the first image, we now treat all "front"
images as candidates.
This is useful where some digital releases have both an animated cover
and a still image and the animated image is the first image returned
from the API.
The Cover Art Archive API offers pre-resized thumbnails of cover
art. If the `maxwidth` option of `fetchart` matches one of the
supported Cover Art Archive thumbnail sizes, and a thumbnail of
that size exists in the Cover Art Archive, fetch it directly
instead of fetching the full size image then resizing it.
The Cover Art Archive API offers pre-resized thumbnails of cover
art. If the `maxwidth` option of `fetchart` matches one of the
supported Cover Art Archive thumbnail sizes fetch it directly
instead of fetching the full size image then resizing it.
*All* URLs were checked manually, but only once per domain!
I mostly concerned myself with URLs in documentation rather than source
code because the latter may or may not have impactful changes, while the
former should be straight forward.
Changes in addition to simply adding an s:
- changed pip and pypi references as their location has changed
- MPoD (iOS app) url redirects to Regelian, so I replaced those
- updated homebrew references
Notable observations:
- beets.io does have HTTPS set up properly (via gh-pages)
- beatport.py uses the old HTTP url for beatport
- as does lyrics.py for lyrics.wikia.com
- https://tomahawk-player.org/ expired long ago, but the http page
redirects to https regardless
- none of the sourceforge subdomains have https (in 2019!)
Today I had some network problems regarding dbpedia.org, which made
beets crash because a requests.exceptions.ConnectionError was raised
("[Errno 113] No route to host"). This commits adds some error handling
around network requests to prevent further crashes in the future.
I did a little audit using the `openssl` command-line tool to find the servers
that don't require SNI. Here's what I found:
icbrainz.org: SNI
images.weserv.nl: inconclusive, but docs say yes SNI
coverartarchive.org: SNI
webservice.fanart.tv: *no* SNI
dbpedia.org: *no* SNI
en.wikipedia.org: *no* SNI
ws.audioscrobbler.com: *no* SNI
api.microsofttranslator.com: *no* SNI
In summary, *only* MusicBrainz and CoverArtArchive were found to require SNI.
So I'm using SSL unconditionally on all the other sites.
