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
9 years
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.
9 years, 1 month
jhbuild for dleyna
by Jussi Kukkonen
Hi guys,
In case someone else is interested:
https://github.com/jku/dleyna-jhbuild
That's my personal jhbuild setup for dleyna, it helps in developing
against bleeding edge components while not breaking every gupnp-based
app on the host system. By default it uses git master HEAD for all
dleyna components and latest release tag for GUPnP components. Default
is to build the components (and dependencies) the metamodule 'dleyna'
defined in dleyna-modules.
How I use it:
* Fetching/building everything
./dleyna-jhbuild build
* building a single component with local changes (e.g. quickly testing patch)
./dleyna-jhbuild buildone -n gupnp
* Running a single command
./dleyna-jhbuild run root/libexec/dleyna-server-service
* Running more things (a jhbuild shell)
./dleyna-jhbuild shell
dleyna-jhbuildrc has paths you will want to change and some useful
options like overriding a repo url and such. More on
https://developer.gnome.org/jhbuild/unstable/
Jussi
9 years, 2 months
