Re: Rygel and DMP support

[Jens Georg <mail jensge org>]

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.

>     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.

> Currently, these two issues are main blockers for us and we are 
> interested in fixing them as soon as possible.If you have any 
> suggestions/comments to any of these issues, we would like to merge our 
> fixes to the upstream.

Appreciated :)