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. _______________________________________________ rygel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/rygel-list
