The backend API is the interface that must be implemented when you create a backend. If you are working on a frontend and need to access the backends, see the Core API instead.
When Mopidy’s core layer is processing a client request, it routes the request to one or more appropriate backends based on the URIs of the objects the request touches on. The objects’ URIs are compared with the backends’ uri_schemes to select the relevant backends.
An often used pattern when implementing Mopidy backends is to create your own URI scheme which you use for all tracks, playlists, etc. related to your backend. In most cases the Mopidy URI is translated to an actual URI that GStreamer knows how to play right before playback. For example:
If there isn’t an existing URI scheme that fits for your backend’s purpose, you should create your own, and name it after your extension’s ext_name. Care should be taken not to conflict with already in use URI schemes. It is also recommended to design the format such that tracks, playlists and other entities can be distinguished easily.
Backend API
If the backend has problems during initialization it should raise mopidy.exceptions.BackendError with a descriptive error message. This will make Mopidy print the error message and exit so that the user can fix the issue.
Parameters: |
|
---|
Actor proxy to an instance of mopidy.audio.Audio.
Should be passed to the backend constructor as the kwarg audio, which will then set this field.
The library provider. An instance of LibraryProvider, or None if the backend doesn’t provide a library.
The playback provider. An instance of PlaybackProvider, or None if the backend doesn’t provide playback.
The playlists provider. An instance of PlaylistsProvider, or class:None if the backend doesn’t provide playlists.
List of URI schemes this backend can handle.
Parameters: |
|
---|
Swith to provided track.
MAY be reimplemented by subclass.
Parameters: | track (mopidy.models.Track) – the track to play |
---|---|
Return type: | True if successful, else False |
Get the current time position in milliseconds.
MAY be reimplemented by subclass.
Return type: | int |
---|
Pause playback.
MAY be reimplemented by subclass.
Return type: | True if successful, else False |
---|
Play given track.
MAY be reimplemented by subclass.
Parameters: | track (mopidy.models.Track) – the track to play |
---|---|
Return type: | True if successful, else False |
Resume playback at the same time position playback was paused.
MAY be reimplemented by subclass.
Return type: | True if successful, else False |
---|
Parameters: | backend (mopidy.backend.Backend instance) – backend the controller is a part of |
---|
See mopidy.core.PlaylistsController.create().
MUST be implemented by subclass.
See mopidy.core.PlaylistsController.delete().
MUST be implemented by subclass.
See mopidy.core.PlaylistsController.lookup().
MUST be implemented by subclass.
Currently available playlists.
Read/write. List of mopidy.models.Playlist.
See mopidy.core.PlaylistsController.refresh().
MUST be implemented by subclass.
See mopidy.core.PlaylistsController.save().
MUST be implemented by subclass.
Parameters: | backend (mopidy.backend.Backend) – backend the controller is a part of |
---|
See mopidy.core.LibraryController.browse().
If you implement this method, make sure to also set root_directory_name.
MAY be implemented by subclass.
See mopidy.core.LibraryController.find_exact().
MAY be implemented by subclass.
See mopidy.core.LibraryController.lookup().
MUST be implemented by subclass.
See mopidy.core.LibraryController.refresh().
MAY be implemented by subclass.
models.Ref.directory instance with a URI and name set representing the root of this library’s browse tree. URIs must use one of the schemes supported by the backend, and name should be set to a human friendly value.
MUST be set by any class that implements :meth:`LibraryProvider.browse`.
See mopidy.core.LibraryController.search().
MAY be implemented by subclass.
Marker interface for recipients of events sent by the backend actors.
Any Pykka actor that mixes in this class will receive calls to the methods defined here when the corresponding events happen in the core actor. This interface is used both for looking up what actors to notify of the events, and for providing default implementations for those listeners that are not interested in all events.
Normally, only the Core actor should mix in this class.
See Backend extensions.