Sorry, you need to enable JavaScript to visit this website.

dLeyna

As an umbrella project, dLeyna hosts a cluster of middleware components for the implementation of Digital Media Servers, Digital Media Renderers, Digital Media Controllers and Digital Media Players. These readily available APIs enable consumer electronics system builders to reduce Build-of-Material costs and time-to-market.

There is only ever a single instance of this object. The manager object exposes one d-Bus interface, com.intel.dLeynaServer.Manager.

Methods

The interface com.intel.dLeynaServer.Manager contains seven methods. Descriptions of each method, along with their d-Bus signatures, are given below.

Signature Description
GetServers() -> ao GetServers takes no parameters and returns an array of d-Bus object paths. Each of these paths reference a d-Bus object that represents a single DMS.
GetVersion() -> s Returns the version number of dLeyna-server.
Release() Indicates to dLeyna-server that a client is no longer interested in its services. Internally, dLeyna-server maintains a reference count. This reference count is increased when a new client connects. It is decreased when a client quits. By default, when the reference count reaches 0, dLeyna-server exits. A call to Release also decreases the reference count. Clients should call this method if they intend to keep running, but they have no immediate plans to invoke any of dLeyna-server's methods. This allows dLeyna-server to quit, freeing up system resources.
PreferLocalAddresses(b Prefer) -> void Indicates whether local addresses should be prioritized or not. DMSs tend to make their services available on multiple interfaces. If a DMP and a DMS are running on the same device, the DMP will have the option of communicating with the DMS over the loopback or the LAN. By default dLeyna-server will return loopback addresses to clients running on the same device. This is not very helpful for DMCs who need non-local addresses to pass to renderers running on other devices. DMCs should therefore call this function with the value FALSE before requesting any URLs from any servers.
SetProtocolInfo(s ProtocolInfo) -> void Informs dLeyna-server of the MIME types and network protocols supported by the client.
Rescan() -> void Forces a rescan for DMSs on the local area network. This is useful to detect DMSs which have shut down without sending BYE messages or to discover new DMSs which for some reason were not detected when either they, or the device on which dLeyna-server runs, was started or joined the network. New in v0.0.2.
GetIcon(s RequestedMimeType, s Resolution) -> (ay Bytes, s MimeType) Returns the device icon bytes and mime type according to the RequestedMimeType and Resolution parameters. Both RequestedMimeType and Resolution parameters are currently reserved for future use and should be set as an empty string. This is a helper function for client applications as it prevents them from having to issue an HTTP request to retrieve the icon. The URL is still available so they are free to continue doing so if they wish. New in v0.0.2.

The explanation behind the final function, SetProtocolInfo, is a little complex, so it's described here and not in the table above. DMSs often support a feature call transcoding. This allows them to publish each media item they manage in a number of different formats. This is useful because not all devices support the same set of media formats and codecs. For example, a DMS might publish two separate URLS for a video file. The first URL might point to the file in its original format, such as, to an ogg vorbis file. The second URL however, could point to a MP4 encoded version of the same file. The second URL might be preferable, if viewing the file on a mobile device. In short, SetProtocolInfo allows clients to specify the formats that they would like to receive media content in. This function should be called by all MediaPlayers. Doing so, will make sure that dLeyna-server returns only compatible URLs using the org.gnome.MediaItem2 interface. For more information, see the Item Objects page.

The ProtocolInfo parameter is a comma separated list of protocol info values. Each protocol info value consists of four fields separated by colons. Unfortunately, the format is too complex to describe in this document. Refer to the UPnP Connection Manager Service Template document and the DLNA Guidelines, where that format is described extensively. However, an example of what the ProtocolInfo parameter might be set to is presented below, to give the reader an idea of what such a string might look like.

"http-get:*:audio/mp4:DLNA.ORG_PN=AMR_WBplus,http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_MED"

The value above indicates that the client supports the retrieval, using HTTP, and the playback of audio MP4 and JPEG files.

Signals

The com.intel.dLeynaServer.Manager interface also exposes three signals.

Signature Description
FoundServer(o) Is generated whenever a new DMS is detected on the local area network. The signal contains the path of the newly discovered server.
LostServer(o) Is generated whenever a DMS is shut down. The signal contains the path of the server which has just been shut down.
LastChange (a{sv}) The LastChange signal is generated by servers to provide precise information of changes that have taken place to their content. LastChange is useful for synchronisation controllers. It allows them to dynamically update their local cache of the server's content. This signal contains an array of zero or more elements, each of which represents a change to a specific object. The format of the data contained in this array is described below.

Last Change Signal Format

The LastChange signal has one parameter. This parameter is an array of tuples. Each tuple consists of a string key and a variant. The type of the variant is determined by the key. Four key values are possible.

Key Values Description
ADD Indicates that an object has been added.
MOD Indicates that an object has been modified.
DEL Indicates that an object has been deleted.
DONE Indicates that an update to a sub-tree has completed.

The format and descriptions of the four variant types are given in the tables below

Dictionary value for key "ADD": Format (oubos)
o Contains the Object Path property of the object that was added.
u Contains the value of the SystemUpdateID when the object was added.
b True if the object was added as part of a subtree update.
o Contains the Object Path property of the parent container to which this object was added.
s Contains the value of the Type (converted upnp:class property) of the object that was added.
Dictionary value for key "MOD": Format (oub)
o Contains the Object Path property of the object that was modified.
u Contains the value of the SystemUpdateID when the object was added.
b True if the object was modified as part of a subtree update.
Dictionary value for key "DEL": Format (oub)
o Contains the Object Path property of the object that was deleted.
u Contains the value of the SystemUpdateID when the object was added.
b True if the object was deleted as part of a subtree update.
Dictionary value for key "DONE": Format (ou)
o Contains the Object Path of the updated sub-tree
u Contains the value of the SystemUpdateID when the object was added.
Project: