(2014-08-11, 22:57)Millencolin007 Wrote: (2014-08-11, 21:13)Tolriq Wrote: As you have reported and was validated in the PR comments, queue and Playlist are not supported with the play with features and it's functions in uncertain at best as validated by Montellese too in the PR and it's answer here.
I think that we are not talking about the same thing. You want to queue files over upnp and then controlling the playlist content using an upnp controller which is not supported.
I refer to using the queue inside of xbmc to play the content on an external player (in this case upnp but it could be any other external player like vlc). Queuing files / playing a full playlist this way works fine (at least for me) as long as you use xbmc to control playback and you don't try to control playback over upnp directly. It works because xbmc will detect the end of the playback and starts playing the next song. Once it plays the last file in the playlist it reverts back to the default player.
No I'm not, as you can see by last answer of Montellese, how XBMC will react is unknown at best.
I do not care about Playlists and queue, they are told to not be supported and not working, it's ok for me, queue have to be handled by remote if they want to be sure that it work it can be normal and a limitation of API.
There's other limitations in API that we have to deal with.
My main concern is about the player.open without playercoreid that can start on upnp or any player depending on things not controlled.
This is the same thing as starting a player.open to start a movie, but the movie will start paused if the player is already in paused state. This is not logical and what the user want, if he trigger the player.open he want the media to start not to be in random unknown state.
Now back to playercoreid, and Player.Open. Since as you confirmed the media can be sent to any current player or a new one it's a bug nothing less.
First reason would be the playercorefactory.xml file that is not used when starting a media, users can configure whatever player they want for some media types and Player.Open does not take it in account if something is already playing ? If this is not a bug I don't know what it is.
So it's logical, normal and user wanted, Player.Open must follow the normal player initialization to choose the correct one and init it correctly.
While the paused feature was just a little side effect, now that this was added in API having media that can start where they want is not wanted.
And no having to query for players, wait answer, stop them, wait answer then start new one, is only a ugly workaround. Send to XBMC features from browsers for example should not have to do all this just to start a media ....
(Since asking directly for playercoreid will bypass the playercorefactory.xml and remote will not be able to reproduce what the user want / have configured).