* Update failing AccurateRipResponse tests [1/2]
The failures seem to be caused by a remote metadata change (metadata from AccurateRip about a release ID changed) which means some of the asserts related to a specific release ID are failing. I've fixed this issue with two commits.
This is part 1: here I've updated the confidence values of two tracks making it agree with AccurateRip's remote.
* Update failing AccurateRipResponse tests [2/2]
This is part 2: here I've replaced the outdated AccurateRip bin file with a freshly downloaded one.
Whipper offset find needs a (remote) matching AccurateRip entry to perform its task and confirm the drive offset: if none is found, return early to prevent exception.
Fixes#208.
Commit 9c72ebccd3 introduced a bug: all template strings are validated against the disc template RegEx (which, for example, is wrong if we're testing the track template).
If the template string contains variables which aren't valid for whipper, raise ValueError exception listing all the included unrecognized variables.
I've also corrected the example template configuration lines in the README.
Fixes#279.
`os.pathconf()` expects a bytes object, but the path is stored as a
unicode object. Since there's no specified encoding, Python chokes when
trying to convert it to a bytes object. Explicitly encoding it as UTF-8
allows Python to change it to a bytes object smoothly.
Fixes https://github.com/whipper-team/whipper/issues/315
* Limit length of filenames
If whipper generated filenames are longer thant the maximum value supported by the filesystem, the I/O operations are going to fail.
With this commit filenames which may be too long are truncated to the maximum allowable length.
Fixes#197.
The values stored in variables _inARDatabase and _accuratelyRipped were double incremented when both AR v1 and AR V2 entries were present e/o matched, leading to a wrong calculation and potentially erroneous summary reporting.
After this fix, in case of double matches only one is counted against each track.
* handle FreeDB server errors gracefully
In my repeated tests, I ended up upsetting freedb.org, which started
issuing 502 errors. Those errors are not correctly caught by the
program which just crashes with a backtrace. Instead, we handle those
like any other API error, which can already be generated by
perform_lookup (but not handled).
The visible result for the user is that the CD is simply not found on
FreeDB, an acceptable compromise, in my opinion.
Closes: #206
* harmonize an error message with other warnings
... which are all capitalized.
* freedb: Import from python-audio-tools 660ee2c
License: GPL-2.0+
* freedb: Remove unused code and set client name to whipper.
The removed functions depend on other classes of python-audio-tools,
but aren't needed here.
* cddb-py: replace with newer freedb implementation
The last release of cddb-py was 15 years ago. The freedb code taken
from python-audio-tools speaks protocol version 6 (Unicode) and is
compatible to both Python 2 and 3.
* freedb: Don't allow the pedantic CI test to fail
* cd/offset: remove unused call to gobject.thread_init()
There are no threads involved.
* task: switch to PyGObject
Python-gobject-2 is deprecated.
* travis: update dependencies for PyGObject and GLib-2.0
* README: Add GObject Introspection
