Check function signature instead of using TypeError to crudely guess
that the wrong number of arguments were provided.
Prevent bpd from crashing when trying to log a traceback. The
`traceback.format_exc` function takes an optional argument which is
supposed to be an integer restricting the length of the backtrace to
show. Instead we were passing the exception object to this function and
causing a new exception to be raised.
Previously issuing the 'previous' command when at position 0 on the
playlist would cause bpd to stop playing. MPD instead just restarts the
currently playing song instead, so we now match this behaviour.
The songs are indexed starting from zero for the play command, however
the bound check was off by one. An index matching the length of the
playlist would crash the server instead of responding with an error
message over the protocol.
The repeat flag indicates that the entire playlist should be repeated.
If both the repeat and single flags are set then this triggers the old
behaviour of looping over a single track.
This command instructs bpd to stop playing when the current song
finishes. In the MPD 0.20 protocol this flag gains a value 'oneshot' but
for now we just support its older version with a boolean value.
The real MPD offers persistent playlist manipulation, storing the
playlists in a directory set in the config file. If that directory is
not available then the feature is disabled and the relevant commands all
respond with errors. Based on this, the initial support in bpd just
returns errors matching the MPD server in the disabled mode.
For playlistadd, extend the _bpd_add helper to work with playlists other
than the queue in order to support testing the real implementations of
these commands in the future.
There's a special status command for checking the replay gain mode,
which can be set to one of a short list of possible values. For now at
least we can ignore this feature, but track the setting anyway.
MPD supports a deprecated command 'volume' which was used to change the
volume by a relative amount unlike its replacement 'setvol' which uses
an absolute amount. As far as I can tell 'volume' always responds with a system
error message "No mixer".
These are a more sophisticated version of crossfade so we're free to
ignore them, at least for now. We now track the values of the two
settings, and show them in the status output. Like MPD, we suppress the
mixrampdb value if it's set to nan, which is how it signals that the
feature should be turned off.
If an MPC client is expecting a command to take an argument that bpd
isn't expecting (e.g. because of a difference in protocol versions) then
bpd currently crashes completely. Instead, do what the real MPD does and
return an error message over the protocol.
Although crossfade is not implemented in bpd, we can store the setting
and repeat is back to clients. Also log a warning that the operation is
not implemented.
The real MPD doesn't show the crossfade in status if it's zero since
that means no crossfade, so now we don't either.
This avoids
```sh
PyGIWarning: Gst was imported without specifying a version first. Use
gi.require_version('Gst', '1.0') before import to ensure that the right
version gets loaded.
```
by silencing E401 import ordering warning
This reverts commit 9c41c39913.
That commit used byte strings for the `if __name__ == '__main__'` pattern,
which was necessary when we were doing unicode_literals. But it is wrong on
Python 3, and now that we're liberated from unicode_literals, we need to go
back to native strings for this comparison.
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.
We need plugins to set their config values at run time instead of module import
time. That is, defaults should be put in the __init__ method. This is easy
enough, but to make it even more convenient, I added a BeetsPlugin.config
field, which is a Confit view into a subsection of the configuration named
after the plugin.
In an attempt to finally address the longstanding SQLite locking issues, I'm
introducing a way to explicitly, lexically scope transactions. The Transaction
class is a context manager that always fully fetches after SELECTs and
automatically commits on exit. No direct access to the library is allowed, so
all changes will eventually be committed and all queries will be completed. This
will also provide a debugging mechanism to show where concurrent transactions
are beginning and ending.
To support composition (transaction reentrancy), an internal, per-Library stack
of transactions is maintained. Commits only happen when the outermost
transaction exits. This means that, while it's possible to introduce atomicity
bugs by invoking Library methods outside of a transaction, you can conveniently
call them *without* a currently-active transaction to get a single atomic
action.
Note that this "transaction stack" concepts assumes a single Library object per
thread. Because we need to duplicate Library objects for concurrent access due
to sqlite3 limitation already, this is fine for now. Later, the interface should
provide one transaction stack per thread for shared Library objects.
