- Adds tests for eot_track vs next_track as we were only testing the one code
path.
- Makes test_random_until_end_of_playlist_and_play_from_start actually test
random and not repeat.
- Adds test_play_track_then_enable_random which is the underlying bug covered
by the regression test for issue #17.
- Replace setting the random seed with mocking out shuffle with reverse. This
makes tests easier to reason about while still being able to test correct
behaviour.
- Increases number of tracks to four to avoid test passing due to symetry in
plain and reversed lists.
- Made test_eot_track_with_random_after_append_playlist actually test eot and
not next.
- Found a test failure in handling of test_random_until_end_of_playlist, fix in
next commit.
- Checks that adding a non local:track:... uri to a playlist and reading it
back works.
- Also fixes mistake in API usage where we assumed lookup still raised
LookupError.
- New API wraps gst.pbutils.Discoverer for mopidy use.
- Custom scanner code removed.
- Callback based async API switched with simpler synchronous API
- Scanner is feed one and one URI and returns the result or raises an error.
- Adds new ScannerError exception for error handling in scanner
- Limits local/scan_timeout to 1000-3600000 i.e. 1s to 1h
- Files with zero duration are now excluded.
- Mtime handling moved out of scanner so we can use it for streams etc.
The test was modified to not fail after a refactoring, making it not test what
it was intended to test at all. This reverts the changes and updates the test
in another way, keeping the original intention.
This is required for e.g. ncmpcpp to detect that an enableoutput/disableoutput
command worked, making it possible to toggle the output back without restarting
ncmpcpp.
It was already called with the argument, and both the MPD and HTTP frontends
handled it/expected it. It was just the default implementation in CoreListener
that lacked the argument.
It doesn't make sense to run Mopidy without extensions registered, thus you'll
need to use setuptools and to run `python setup.py develop` anyway. Doing so
makes running `mopidy` from anywhere in the development virtualenv work,
removing any need for running `python mopidy/`.
