[floatingcloud]

Given that "Play Using" allows for the renderering of media files to be offloaded to another destination, thus relieving the xbmc host of doing the heavy lifting for audio/video playback, it stands to reason that xbmc should be able to serve multiple renderers.

Thus I would like to select "Play Using" for a CD to the stereo unit that plays a tune or two whilst I cook in the kitchen and at the same time be able to do "Play Using" and play a movie back to the TV in the living room. And so on throughout the house.

A single instance of xbmc becomes the focal point of media in my house.

What's not to love about that?

[Ned Scott]

It would add some significant complication to XBMC's UPnP controller and UI to have two playback controls. I don't know the details, not being a developer myself, but I don't think I've seen any UPnP app that did multi targets (I haven't looked that hard, so they could very well exist).

However, this is possible using a second UPnP controller. Basically UPnP can be divided into three parts:

Source files -> Controller -> Playback

XBMC can be one, two, or even all three of these. In this case XBMC would be "Source files" and "Playback" (Playback being a second XBMC device, I assume?), but the controller would be something like one of the various UPnP control apps for iOS or Android, for example. That could be the music controller, then XBMC itself could be the controller for movies.

The single XBMC "Source files" would still be serving everyone up.

[Montellese]

As NedScott has pointed out the main problem is that XBMC currently does not support multiple players being active at the same time because it makes the user interface a nightmare. You need some way to control the players and having multiple player controls on the screen would probably be very confusing.

Also changing this would require a huge amount of refactoring because basically the whole playback-related code is written with the assumption that at most one player can be active at any time.

[floatingcloud]

So ... I notice that there is also an "xbmc server" fork that appears to be just a "database" for xbmc.

Maybe serving multiple files belongs there?

Afterall, if a version/fork of xbmc is just streaming to renderers then there is no need to playback (or render) locally, rght?

Or if not, should it be another kind of fork altogether?

However the challenge would be in controlling the playback of each file - play, pause, fast forward, etc.

[Montellese]

It won't work in the "xbmc server" either because the upnp controller is just another player controlled by XBMC like everything else. It may not have a renderer (which is done by the upnp client/renderer) but it still needs to be controllable from within xbmc.

[olegkirillov]

You complicate things more than needed.
In fact we don't need a separate player interface for each renderer - if we want the same playlist to be pushed to several renderers at once, we probably also want the same parameters for every one of them. So we may live with the single player interface instance for a while.

I'm tinkering with Dyne.Org's AVremote CLI now. It does the job well sending a play command to a specified renderer, but it's quite a task to get a playlist contents (URI's) from Media Server.

[nickr]

That is true if you want to play the same media on all renderers, but this thread is about sending different media to multiple renderers. For which I think something like yatse might be better (or any of the network based remote control apps.)