non-compliant MediaObject2.Type values
by Jussi Kukkonen
Hi,
First, doc/API.txt seems to be missing from dleyna-server repo. If the
idea is that only web page is updated, we should probably include a
url in docs/.
API.txt from media-service-upnp says this (looking at code, it seems
to accurately describe dleyna-server):
> Additional Values for the Type Property:
> ----------------------------------------
>
> The Type property tells what kind of object we are dealing with and
> which can take the below values in addition to those described
> in MediaServer2Spec specification (3).
> in case of Items:
> 'video.musicclip', 'video.broadcast'
> 'audio.broadcast', 'audio.book',
> 'playlist', 'item'
> and in case of Containers:
> 'album', 'album.music', 'album.photo'
> 'person', 'person.musicartist'
> 'genre', 'genre.music', 'genre.movie'
I think this is a mistake and makes the implementation non-compliant
with the org.gnome.MediaObject2 spec in a way that is harmful to
client developers. I realise there are other places where
dleyna-server does not implement some things or implements additional
things, but this is more problematic, basically an API break: The
MediaObject2 spec clearly says containers _must_ have type
"container", and applications will rely on that. Adding new types will
break clients.
As an example of this, dleyna-control makes this mistake -- I can't
browse by artist or genre:
https://github.com/01org/dleyna-control/issues/8. As another example
even the same document (API.txt) includes this example:
> def tree(server_path, level=0):
> bus = dbus.SessionBus()
> container = dbus.Interface(bus.get_object(
> 'com.intel.media-service-upnp', server_path),
> 'org.gnome.UPnP.MediaContainer2')
> objects = container.ListChildren(0, 0, ["DisplayName", "Path", "Type"])
> for props in objects:
> print " " * (level * 4) + ( props["DisplayName"] +
> " : (" + props["Path"]+ ")")
> if props["Type"] == "container":
> tree(props["Path"], level + 1)
I believe this will not work for all containers.
If the additional container types are required, could we add another
property for them instead?
- Jussi
7 years, 6 months
Bug#710237: ITP: dleyna-server -- DBus service to interact with DLNA Digital Media Servers
by Emanuele Aina
Package: wnpp
Severity: wishlist
Owner: Emanuele Aina <emanuele.aina(a)collabora.com>
* Package name : dleyna-server
Version : 0.0.2
Upstream Author : dLeyna Development Group - Intel OTC
* URL : https://01.org/dleyna/
* License : LGPL-2.1
Programming Lang: C
Description : DBus service to interact with DLNA Digital Media Servers
dleyna-renderer is a DBus user session service that allows clients to
discover and manipulate DLNA Digital Media Servers (DMS).
.
dLeyna is an umbrella project hosting a number of middleware components
designed to make it easy for developers to integrate DLNA functionality into
their applications.
7 years, 7 months
Bug#710236: ITP: dleyna-renderer -- DBus service to interact with DLNA Digital Media Renderers
by Emanuele Aina
Package: wnpp
Severity: wishlist
Owner: Emanuele Aina <emanuele.aina(a)collabora.com>
* Package name : dleyna-renderer
Version : 0.0.2
Upstream Author : dLeyna Development Group - Intel OTC
* URL : https://01.org/dleyna/
* License : LGPL-2.1
Programming Lang: C
Description : DBus service to interact with DLNA Digital Media Renderers
dleyna-renderer is a DBus user session service that allows clients to
discover and manipulate DLNA Digital Media Renderers (DMR).
.
dLeyna is an umbrella project hosting a number of middleware components
designed to make it easy for developers to integrate DLNA functionality into
their applications.
7 years, 7 months
Bug#710235: ITP: dleyna-connector-dbus -- DBus connector module for the dLeyna services
by Emanuele Aina
Package: wnpp
Severity: wishlist
Owner: Emanuele Aina <emanuele.aina(a)collabora.com>
* Package name : dleyna-connector-dbus
Version : 0.0.2
Upstream Author : dLeyna Development Group - Intel OTC
* URL : https://01.org/dleyna/
* License : LGPL-2.1
Programming Lang: C
Description : DBus connector module for the dLeyna services
dleyna-connector-dbus is the loadable module providing DBus connectivity to
the dLeyna services.
.
dLeyna is an umbrella project hosting a number of middleware components
designed to make it easy for developers to integrate DLNA functionality into
their applications.
7 years, 7 months
Bug#710233: ITP: dleyna-core -- Utility functions for higher level dLeyna components
by Emanuele Aina
Package: wnpp
Severity: wishlist
Owner: Emanuele Aina <emanuele.aina(a)collabora.com>
* Package name : dleyna-core
Version : 0.0.2
Upstream Author : dLeyna Development Group - Intel OTC
* URL : https://01.org/dleyna/
* License : LGPL-2.1
Programming Lang: C
Description : Utility functions for higher level dLeyna components
dleyna-core is a library of utility functions that are used by the higher
level dLeyna libraries that communicate with DLNA devices, e.g.,
dleyna-server. In brief, it provides APIs for logging, error, settings and
task management and an IPC abstraction API.
.
dLeyna is an umbrella project hosting a number of middleware components
designed to make it easy for developers to integrate DLNA functionality into
their applications.
7 years, 7 months
X_DLNA_Seek* and seek values in
by Sébastien bianti
Hi all,
I wonder what is the correct behaviour when receiving from a renderer
that kind of TransportActions:
⋅ X_DLNA_SeekTime or X_DLNA_SeekByte without seek :
1) The renderer is unable to seek, we consider the X_DLNA_… as a mistake.
2) We consider that the renderer is able to seek by time or byte and we
don't care about the omission.
⋅ seek,X_DLNA_SeekByte but no X_DLNA_SeekTime :
1) The renderer is able to time and byte seek because «seek» alone means
time seekable in UPnP-AV.
2) The renderer is only able to seek by byte if no, how to signify "I
can only seek by byte" ?
Opinions welcome.
Sébastien Bianti.
7 years, 8 months