- Adds stream changed handler to core
- Moves playback started trigger to stream changed
- Made about to finish store next track in _pending_tl_track
- Set the pending track as current in stream changed
- Adds tests for all of this and fixes existing tests
Only handles the playing case, unlike the previous and next changes. It should
also be noted that this is just a temporary state on the road to making this
method handle gapless.
While trying to remove traces of stop calls in core to get gapless working I
found we had no way to switch to switch tracks without triggering a play. This
change fixes this by changing the backends playback provider API.
- play() now _only_ starts playback and does not take any arguments.
- prepare_change() has been added, this could have been avoided with a kwarg to
change_track(track), but that would break more backends.
- core has been updated to call prepare_change+change_track+play as needed.
- tests have been updated to handle this change.
Longer term I hope to completely rework the playback API in backends, as 99% of
our backends only use change_track(track) to translate URIs. So we should make
simple case simple, and handle mopidy-spotify / appsrc in some other way.
Fixes case where we could have an empty album. We could alternatively be more
conservative and only limit to fully empty albums. But I think we only want
ones with names anyway.
This adds basic checks for the library provider lookup:
- Check that uri schemes are respected
- Check that blacklisting and globbing works
- Check uri successfully gets converted to a track
Adds a new get_currents_tags method for fetching the full set of current tags.
There are still some untested cases for this, and I also suspect we still want
some API refinements one core starts using this.
Newer versions of the protocol have removed this tag, so we should as well.
This also works around the issue of #881 which was breaking things with
newlines in comment fields.
The readcomments command seems to replace this, but it seems to only care about
specific extra tagtypes, not the general comment tag we normally collect when
scanning things.
(cherry picked from commit 08a8d5c43b)
This was disabled together with a bunch of other changes without any
explanation in commit f24ca36e5a. I'm
guessing that this wasn't intentional, and no test covered the case.
(cherry picked from commit 4e508cd017)
Newer versions of the protocol have removed this tag, so we should as well.
This also works around the issue of #881 which was breaking things with
newlines in comment fields.
The readcomments command seems to replace this, but it seems to only care about
specific extra tagtypes, not the general comment tag we normally collect when
scanning things.
This was disabled together with a bunch of other changes without any
explanation in commit f24ca36e5a. I'm
guessing that this wasn't intentional, and no test covered the case.
