Re: Rygel and DMP support

[Jens Georg <mail jensge org>]

On Di, 2013-10-08 at 20:39 +0200, Milan Plzik wrote:
> On 10/07/2013 11:24 AM, Jens Georg wrote:
> > On Mi, 2013-10-02 at 10:13 +0200, Milan Plzik wrote:
> > > Good day,
> > >
> > >     company I work for considers to use Rygel/gupnp/... as a UPnP stack
> > > in one of its products.  After some basic analysis and testing, we found
> > > out some limitations we would like to discuss:
> > >
> > >      1) RygelMediaPlayer and playlist/multi-track support
> > >
> > >
> > >      RygelMediaPlayer's interface does not provide API (nor any other
> > >      public clas does) making playlist handling possible (e.g.
> > >      next/previous commands, and also reporting of both current media and
> > >      track).
> > Correct. The current implementation wasn't really done with DMPs in
> > mind.
> >
> > >      Since Rygel handles playlist logic internally in
> > >      RygelPlayerController, it can lead to cases where next/prev controls
> > >      don't work (if media playback was initiated via rygel, local UI does
> > >      not know about media and vice versa).
> > >
> > >      Without breaking ABI, this might be solvable by making
> > >      RygelPlayerController public and enabling user to re-implement it,
> > >      but it would be good to discuss this a bit more to have merge-able fix.
> > We can break ABI, we might even have to for the next stable, there's
> > some DLNA testcase fixes for the renderer that can't be done in a nice
> > way without breaking ABI. I already prepared a branch for that. But
> > making the controller public might make sense anyway.
>
>    The question is, what is better. Current RygelMediaPlayer is readily 
> usable by simple players like gst playbin, offloading almost any of 
> necessary logic to rygel code; I guess currently finds a lot of uses. It 
> might be useful to have RygelPlayerInterface (or any better name, this 
> might plug into RygelMediaDevice), which would work as a thin layer 
> between upnp stack and some client plugged into rygel.
>
>    RygelPlayerController would need to be rewritten to implement 
> RygelPlayerInterface, and to provide a way to plug RygelMediaPlayer into 
> it (providing simplified interface for simple players).

Have to think about this a bit.

> > >      2) Error reporting
> > >
> > >      Rygel's API is not designed to allow error reporting (error codes)
> > >      from player to UPnP control point in first place; e.g. there is no
> > >      way to report an error client when invoking play() while no media is
> > >      set. Rygel's code currently does not handle these cases and there is
> > >      no hint about whose responsibility is to return error code. If it is
> > >      solely rygel's responsibility, we will gladly supply patches which
> > >      fix this behavior, otherwise the API might need significant changes.
> > Hm, correct. The initial idea was that it would be Rygel's
> > responsibility.
>
>    In some cases (and maybe in more, when considering DMP), error 
> reporting might be necessary. Currently, only presence of the resource 
> on network (rygel is does not do any checking by itself) comes to my 
> mind. This is problematic probably only within context of Play() and 
> SetAVTransportUri(), maybe Seek(). Maybe some other parts of 
> RygelMediaPlayer implementations may be also dependant on external 
> state, though.

Presence of the resource is checked in SetAVTransportURI but you're
right, it's not done when the URI comes from a playlist.