[Millencolin007]

I tried to send content over upnp from one xbmc server another xbmc server with upnp enabled ( using Gotham or Helix)

It probably depends on the features supported by the upnp renderer. Some upnp implementations support subscribing to events others don't support it. Further some upnp renderer support setting the next url to be played on the upnp renderer using SetNextAVTransportURI. If your tv does not support the feature xbmc tries to use it probably fails to play the next item. But I am not an expert in upnp...

[Tolriq]

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

[Tolriq]

So I suppose but will still stays broken for Helix despite all the impacts

[Montellese]

I agree that there are some issues (some of them are JSON-RPC specific while others aren't) but if you think the new stuff is too buggy then just don't use it. Just continue sending your Player.Open requests without any "playercoreid" property and all should be the same as it was before.

[Tolriq]

As I explained earlier no

If you are playing something the Player.Open will use the current player in lots of cases (This is proved by the pause bug : Just start a movie, pause it at any place then Player.Open an other movie, the movie will be paused and seeked at the previous player position, meaning that the player is not reset and started on Player.Open).

And as reported by Millencolin007 if you are playing on a network player, Player.Open have a chance to get to the same network player if not forcing a playercoreid. (that is not possible due to the playercorefactory like on rpi, playing on dvdplayer or omxplayer is not something remotes can guess for the moment unless you had an api like getPlayerForMedia(...) that return the correct playercoreid.

The problem is not me using the API it's the fact that since there's an API users will use it and as such encounter the wrong player selection and users will then ask remote authors why, meaning lot's of support.

If you read correctly all my posts here and in the PR, the problem is really not about the unfinished API, it's about the Player.Open that have a little flaw of not reseting correctly the player, and that this little flaw is now becoming a much more important one due to this new possibles players from the API.

I only ask something that is logical and defined by the name of the function: Player.Open have to reset the player when starting a new media and not working with playlists.

[Montellese]

If you are playing something the Player.Open will use the current player in lots of cases (This is proved by the pause bug : Just start a movie, pause it at any place then Player.Open an other movie, the movie will be paused and seeked at the previous player position, meaning that the player is not reset and started on Player.Open).

As I have mentioned before this is NOT a bug in Player.Open. The same behaviour is there when you do it all in XBMC's/Kodi's user interface i.e. go into the list of movies, start one, pause it, jump out into the movie list, start another movie and you will end up in fullscreen video playback with the new movie but in paused state. So this needs to be fixed in XBMC's core and NOT in Player.Open.

[Tolriq]

Well I've read again all you posts here and in the PR and nowhere you explain that

Anyway since I now have a build system up to test the TAG thing I'll look into that too.

[Tolriq]

After a quick look it's out of my competence, there's about 500 different cases all mixed together in tons of if else

I have not enough knowledge on this part to be efficient and I suppose the comment //g_application.StopPlaying(); is there for a reason since it's there from before Eden and I suppose nobody will remember why

I suppose this will stay like that and I'll add an entry to the FAQ.

[Montellese]

I've had a look as well and I think I know what's missing but I don't know that code either so it may be for a reason. I've forwarded the issue to some people who might/should know better.

[Montellese]

I've narrowed the problem down to its core issue and asked FernetMenta to look into how to fix it since he's much more familiar with the code. Here's the PR5308.

[Tolriq]

Thanks for the fix for the play / pause bug.

But this does not address the random previous player in some cases. Would you accept a PR that force a stop when optionPlayer is null or any solution that would fix this ?

[Montellese]

TBH I'm not sure what the expected behaviour would be. In the end probably every user expects this to behave differently. Some would expect the next item to be played with the default player, others would expect it to run on the same player as the previous item. Personally I'd expect the new item to be played with the default player if the "playercoreid" option in the Player.Open command would be empty but I can't speak for anyone else.

[Tolriq]

Well I think the same as you, specially since the new playercoreid API.

A possible workaround would be to allow -1 as playercoreid to force the default player and a stop.
Or null stop as default.
Or add a new parameter like stop or reset before play.

But as explained earlier, right now a remote to force a play on default player have to ask for active players, wait for result, send a stop to all of them, wait for success then player.open.
This is quite insane since if a remote want to continue on same player it just have to add the playercoreid that it already have from previous query.

From an API point of view and usage point of view, having Player.Open to force reset by default is more logical and efficient.
But a new parameter could also be ok if there's no other way.

But not having anything to force it, is not good.

[Millencolin007]

I think that it is important that Player.Open (without providing a playercoreid) behaves the same way as if you would execute the same action from the xbmc ui.
Example: if you click on another item of the current playlist I would expect it to play the same way as if you would use Player.Open without playercoreid. (last time I checked it continued playback on the external player)

As described in following thread (UPnP "Play-to/with", SwitchPlayer)
Making UPnP shine for Gotham
the play-to/with feature could work like Airplay / Chromecast where you can select an alternative player which will be used until you "disconnect".
Currently there is no button in xbmc to revert back to the default player (appart of using "y" on the keyboard to display the selection of players). Most of the time it automatically falls back when playback ends or the end of a playlist is reached. Maybe we could find a better way to indicate to the user that he as an external player active when he tries to play the next item. Maybe a SwitchPlayer json-rpc function could also be useful to switch the playercoreid and providing -1 as playercoreid to force the default player could be useful as well.

[Montellese]

Yeah allowing -1 as the default player might be the best approach. The problem will be to determine the default player because IIRC there's a whole lot of logic done to get the actual item to play (to handle stacked items, plugins and what not) before the default player can be determined reliably.