Due mostly to some improvements in Confit, we now have a reasonable way to
define the default filenames of auxiliary data files. These are relative to the
beets config directory (i.e., alongside config.yaml).
Renamed fuzzy_search to fuzzy and rdm to random. These names should be easier
to remember since they are the same as the commands they provide.
--HG--
rename : beetsplug/fuzzy_search.py => beetsplug/fuzzy.py
rename : beetsplug/rdm.py => beetsplug/random.py
rename : docs/plugins/fuzzy_search.rst => docs/plugins/fuzzy.rst
rename : docs/plugins/rdm.rst => docs/plugins/random.rst
The changes introduced in rc1 caused paths to be syspath-ified before they were
passed to os.path.abspath. The magic prefix caused them to be interpreted as
absolute paths even if they were relative. The fix is, in this *isolated*
case, to use Unicode but prefix-free paths in calls to the os.path.* functions.
Those functions need to act on Unicode objects but seem to be purely syntactic
-- nothing is tripped up by using long filenames without the magic prefix.
A simple plugin that connects to the EchoNest API to retrieve
tempo (bpm) metadata for tracks. Functions similarly to the lyrics
plugin.
Requires the pyechonest library.
@yagebu: I did a code review of the new version of convert using FFmpeg as a
backend. Everything looks perfect. These are just a few changes to the docs.
Thanks again!
Instead of flac and lame the convert plugin now uses ffmpeg. This adds
support for more input formats and simplifies the code. ffmpeg also uses
the lame encoder internally and has equivalents of all the -V<num>
presets which should be sufficient.
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.
Also pertaining to #58: for most utility functions, paths should *not* be
`syspath`-ified. (This only occurs right before a path is sent to the OS.) In
fact, as @Wessie discovered, using the result of `syspath` with `ancestry` leads
to incorrect behavior. I checked and this should not currently happen anywhere,
but these docstring changes make that requirement explicit.
With the new centralized print_obj function, we can greatly simplify the code
for the list command. This necessitated a couple of additional tweaks:
- For performance reasons, print_obj can now take a compiled template. (There's
still an issue with using the default/configured template, but we can cross
that bridge later).
- When listing albums, $path now expands to the album's item dir. So the format
string '$path' now exactly corresponds to passing the -p switch.
As an added bonus, we can now also reduce copypasta in the random plugin (which
behaves almost exactly the same as list).
This version of the (renamed) _print_obj function uses introspection to
determine whether we're printing an Album or an Item. It's like function
overloading for Python! 😁
We now always calculate album gain when importing an album. This is "free" (no
performance cost) now and players are free to ignore the setting if they so
choose.
This is fixed by allowing MediaFiles to convert strings to integers on
assignment. An eventual complete fix will perform these type conversions in the
Item interface.
Eliminate the __subclasses__ trick for finding all plugins. Now we explicitly
look in each plugin module for a plugin class. This allows us to import plugin
modules with unintentionally loading them. This lets us reuse the image
embedding machinery without copypasta.
When we store paths in the database, we always use bytestrings for consistency.
But on Windows, these paths are converted back to Unicode before they reach the
FS API. This means that the codec used internally is immaterial.
However, we were naively using sys.getfilesystemencoding() for this internal
representation. On Windows, this is MBCS, a broken encoding that can't represent
all of Unicode. This change replaces that with UTF-8, a "real" codec.
The decoding bit now tries UTF-8 and falls back to MBCS for compatibility with
existing databases. The reality, however, is that existing databases may not
work with this change -- a byte string may represent something different in
UTF-8 from what it represents in MBCS. So users should recreated their DBs if
anything goes wrong.
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.
