[spud.webb]

Is there a way to trigger the "Play With" feature from the JSON RPC API.?

I saw that there is a PlayWith function in the BuiltIn commands (Builtins.cpp). So is it possible to execute a BuiltIn command from JSON RPC?

[Montellese]

Only selected builtin methods are available and PlayWith isn't one of them. You'd need a way to get a list of available players as well.

[spud.webb]

How hard it is to add?

I'm the developer of the HomeSeer plugin for XBMC (http://board.homeseer.com/forumdisplay.php?f=1149), and I would like to add this feature.
I can live without a JSON call to get a list of available players, as my program already discovers all the available XBMC players.

[Montellese]

See PR5122.

[spud.webb]

Nice. Thank you!

[spud.webb]

is this enhancement going to be merged in Gotham?
or do I have to wait for Helix?

[Montellese]

Gotham only gets bug/crash fixes so you'll have to wait for Helix.

[Millencolin007]

See PR5122.

This looks like a great new feature for Helix. I just tried out the new "Play with" feature using json-rpc and wanted to give some feedback / bugs

The following happens when I use "Play with" to start playback on a different xbmc instance over upnp (using the xbmc gui):
- Playback is started over upnp on the other host
- XBMC will displays the currently playing file and duration and cannot be used for local playback while using "Play with". Play / Pause can be used to control playback. Seeking did not work, next / previous will play the next item over upnp.
- If I tried to control the upnp renderer from an upnp application it was not able to play the next item in a playlist (probably not implemented on xbmc).

Now to the json-rpc related stuff
- Returning the list of players works fine
- Playing a movie / episode etc using Player.Open and specifying the playercoreid also works and the file is played on the other machine.
- When I use Player.Open together with playlistid / position it does not start playback using the requested player

Code:

curl  -H "Content-Type: application/json"  -d "{\"jsonrpc\":\"2.0\",\"method\":\"Player.Open\",\"params\":{\"item\":{\"playlistid\":0,\"position\":1},\"options\":{\"playercoreid\":5}},\"id\":1}" http://127.0.0.1:8080/jsonrpc

Looking at the code It seems to ignore the playercoreid because it jumps into an "if block" on line 524 of PlayerOperations.cpp, function open.. and therefore does not execute the logic to change the player. Any special reason for not including this?

- When playing a file over upnp, xbmc displays the currently playing item on the screen. Requesting the active players or the current item over json rpc doesn't return anything. Would be nice if this data could be made available over json-rpc. Note: Notifications for start / stop are sent over port 9090 when playing a file over upnp.

Remark: If a file is playing using "Play with" and you try to play another file it will also automatically be played over upnp as long as you did not stop playback / reach the end of the queue which then probably resets the player. ( I think it will play as long as g_application.m_eForcedNextPlayer is not reset to the local player). => Using Player.Open without specifying the playercoreid may still play the next item over upnp. But I think this is ok, since xbmc behaves the same way when you select an item for playback.

[Montellese]

This looks like a great new feature for Helix. I just tried out the new "Play with" feature using json-rpc and wanted to give some feedback / bugs

Thanks.

- XBMC will displays the currently playing file and duration and cannot be used for local playback while using "Play with". Play / Pause can be used to control playback. Seeking did not work, next / previous will play the next item over upnp.

Yes there's no local playback while playing something on another UPnP renderer as XBMC can only control one player at a time whether local or remote. Concerning seeking I've seen videos where it worked and others where it didn't but never had the time to investigate.

- If I tried to control the upnp renderer from an upnp application it was not able to play the next item in a playlist (probably not implemented on xbmc).

Playlist support is not really there in XBMC's UPnP implementation (because the playlist support specified in the UPnP specification is very lacking).

- When I use Player.Open together with playlistid / position it does not start playback using the requested player

Code:

curl  -H "Content-Type: application/json"  -d "{\"jsonrpc\":\"2.0\",\"method\":\"Player.Open\",\"params\":{\"item\":{\"playlistid\":0,\"position\":1},\"options\":{\"playercoreid\":5}},\"id\":1}" http://127.0.0.1:8080/jsonrpc

Looking at the code It seems to ignore the playercoreid because it jumps into an "if block" on line 524 of PlayerOperations.cpp, function open.. and therefore does not execute the logic to change the player. Any special reason for not including this?

Because our UPnP implementation does not really support playlists (as already mentioned above). Using the "Play next/previous" buttons in XBMC controlling the renderer works to play the next/previous item because XBMC knows what the next item is. But if you start a video (or song) on the remote renderer and let it play to the end it won't start playing the next item in your playlist. That's why the "playercoreid" option only works with the "item" parameter and not with playlist.

- When playing a file over upnp, xbmc displays the currently playing item on the screen. Requesting the active players or the current item over json rpc doesn't return anything. Would be nice if this data could be made available over json-rpc. Note: Notifications for start / stop are sent over port 9090 when playing a file over upnp.

I'll have to look into that.

[Millencolin007]

Because our UPnP implementation does not really support playlists (as already mentioned above). Using the "Play next/previous" buttons in XBMC controlling the renderer works to play the next/previous item because XBMC knows what the next item is. But if you start a video (or song) on the remote renderer and let it play to the end it won't start playing the next item in your playlist. That's why the "playercoreid" option only works with the "item" parameter and not with playlist.

Yes, the UPnP implementation does not support playlists so you will not be able to control the play queue over upnp.

However you can try the following: Add some (music ) files to the play queue in xbmc, then show the play queue on xbmc and start playback using "Play with" => it will play the full playlist on the upnp renderer ( or whatever external player you have selected ). Basically it plays one file on the upnp renderer and once playback is done it will send the next song from the xbmc queue to the upnp renderer (or external player) => No upnp playlist support is required for that.

PS: If you look at my example request from the previous post it also uses the "item" parameter but with playlistid / position

It is probably enough to add g_application.m_eForcedNextPlayer = playerId; (with all the checks if the selected playercoreid is valid)
somewhere around line 544 in PlayerOperations.cpp to make playback also work using playlist position.
https://github.com/Montellese/xbmc/blob/...s.cpp#L544

[Tolriq]

Remark: If a file is playing using "Play with" and you try to play another file it will also automatically be played over upnp as long as you did not stop playback / reach the end of the queue which then probably resets the player. ( I think it will play as long as g_application.m_eForcedNextPlayer is not reset to the local player). => Using Player.Open without specifying the playercoreid may still play the next item over upnp. But I think this is ok, since xbmc behaves the same way when you select an item for playback.

Since this remark was not in Montellese answer I permit to quote it back, as it was one of the main concern of my comments on the PR, since this would introduce the need to query for internal ids before playing normal content.
Or to force the send of stop, and since as told multiple times by topfs we should not rely on batch commands for ordering this would be a total mess.
For me as explained in the PR this is not ok, as you lose control to return on XBMC

And it's surely tied to my report in JSON RPC thread, that is quite disturbing for users.

Start any media, move to a given position then pause it.

Next call to Player.Open will open the new media but will seek to the same position and left it paused.
A call to play will start the media from the start.

[Millencolin007]

The behavior I have explained has nothing to do with the PR since it describes the "Play with" implementation.

xbmc does not have a button like the "chromecast cast" button to tell xbmc to play its content on another device therefore it has to rely on another way to decide when to switch back to the local player. It seems that it uses the "stop" event to revert back which seems a good approach to me.

If I have some files in the queue and start playback using "Play with" I would want xbmc to play all the files from the queue on the other device and not only the current file and revert back to the local player. Now if you manually start playback of another file you expect it to play locally but since you didn't send a stop command it may also play on the other device. The first reaction of the user will be to stop the playback... and the player reverts to the default value

Sending a stop command before starting playback should not be a problem. If you are concerned about batches out of order you can send the stop command, wait for the stop notification to be sent on port 9090 and start playback or simply wait a second or two before sending the play command. Or in Helix you could use Player.Open and specify the playercoreid to force the internal player

[Tolriq]

Well you may want to read all the comments on the PR

I never said the PR was in cause I just reported problems and limitations, and asking for playtercoreid for internal player is out of question since id are said to be changing and should be asked before every commands.
Sending a stop to an rpi then wait then send the commands is not only very slow but very inefficient for battery and network usage.

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.

So yes there's inefficient workarounds and hacks but nothing correct for a long term usage of such features, so it misses an important part, either support queuing properly and officially or not, but in either case there's missing part to have something that you can explain to end users.

[Millencolin007]

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.

[Montellese]

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.

I tried that when I created the PR and I tried it yesterday again and it doesn't work for me (at least not with my Samsung TV, will try with my RPi today or tomorrow). No matter how I start/queue the items the next item will be played locally after the previous item has finished. If I use the next/previous item functionality it however does play the next item on my Samsung TV.

That's why I didn't add support for playercoreid in combination with playlistid.