Posts: 90
Joined: Jan 2010
Reputation:
0
And really, when you get down to it, if xbmc instances can all communicate with each other this is all you need.
A listing of zones showing what is currently playing (or if nothing, system status, in this mockup in parentheses such as (OFF) or where in the GUI that instance is currently (WEATHER)).
Two options:
(1) Control (radio button 'on' and zone highlighted), and monitor (arrow). Control simply means the local xbmc is now controlling the actively selected zones, which may or may not (as in this example) include the local instance. When you have whatever zones active that you wish, local, another, multiple, whatever, leave the Zones blade and return to your normal XBMC experience. The key is that now all of your actions of navigating through menus, selecting tv streams or stored media, changing system settings, turning up the volume... will issue commands to the active zones. If you want only local control, select only the local zone. If you want to only change what the kids are watching, select only that zone and not local.
(2) Monitor (right arrow on whatever zone is currently in selection focus). This just clones your local instance to the same stream or media file as the selected instance. Now that I think of it, you need some way to know which zone is in selection focus (though not necessarily selected as active), so I guess the blue should be in focus and the radio button should signify active. Only needed one "blue" highlighted zone in my mockup. Shoot me.
But I hope this illustrates that perhaps the GUI isn't such a hurdle if there is work and thought put into how multizone/multi-instance/multi-something actually works. My goal was to show that not much really needs to be added to the GUI. XBMC already has about the best GUI (in as many flavors as you want!) possible allowing full control over anything and everything. No need to recreate methods for selecting media or anything else, just a method of specifying "for which XBMC?" And for the little time I spent on this, I'm sure there are plenty of much more talented skinners that could do a more polished job.
You said "show me an example" before it would even be considered for support among core devs and core xbmc function (i.e. not needing a plug-in that can never operate as elegantly - no disrespect intended teshephe). Does this example even come close?
Posts: 4,549
Joined: Dec 2007
Reputation:
17
topfs2
Team-Kodi Developer
Posts: 4,549
2010-09-26, 14:31
(This post was last modified: 2010-09-26, 14:35 by topfs2.)
tbh I am not a fan of the suggestion while I can agree its not overly complicated, more dialogs means more work for skinners and since this is such a minimal amount of people that would use the feature it would probably just annoy skinners. And skinners already have tons of dialogs and windows to do so adding more is not a good thing always. Still this is what I want to see, proper mockup how it could work which aren't overly complicated so keep it up!
At any rate, if thats all you need a script fits the bill perfectly. What you would need is perhaps a way to add widgets to the home screen in an abstracted matter (like kde4 or android). Now thats a feature suggestion that could actually be interesting...
If you need to play audio from client a to client b then it starts to become harder to manage in core and I really doubt that will happen. But if widgets would be popular and this widget would be popular who knows, as it stands now its months of work for something perhaps 1% would use.
If you have problems please read
this before posting
Always read the
XBMC online-manual,
FAQ and
search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the
forum rules.
For troubleshooting and bug reporting please make sure you
read this first.
"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Posts: 90
Joined: Jan 2010
Reputation:
0
I can appreciate that it would add complexity for skinners. I took a look at the confluence artwork and XML files and was amazed at how much work must go into producing a skin. But were talking about a single additional dialog requiring only a couple of graphics which should be leveraged wholesale from existing pages functions, so I can't imagine that this is any serious increase in the time required to produce a skin in the big picture. But if it can be added on as a script that ties directly into the homescreen and core functions like this then I'm going to certainly learn more about that as I get time.
The more I think about it the more I see the major roadblock is actually having xbmc act as a listening client like streamcast stuff. Otherwise, you might be telling six xbmc instances to all pull the same song or video from the server simultaneously, which is a huge waste of bandwidth and could cause problems. I don't think devs are interested in separating xbmc into explicit server and client components to have it function in this way and I can't blame them. If that ever becomes a popular idea then that would be the ideal time to revisit this one.
In the meantime I'm going to be very busy but I've been looking for a reason to learn something more than an interpreted language so maybe this will be motivation. Again, I think the possible benifits and future flexibility go far beyond simple multizone audio.
Posts: 152
Joined: Nov 2011
Reputation:
0
xbmcg
Senior Member
Posts: 152
Great mockup. In general it would be great to have this function. The UI can even be reduced to three additional functions in the context menus:
- one in the library view of the content saying: play to location (and a dynamic list of xbmc instances on the local network - recognized by upnp protocol or so. This can be used to remote control á xbmc instance / start playback in a different room).
- the second on the playback menu (M-Key) saying extend playback to (with a popup of active xbmc instances) to add playback of the running content to other rooms (multiroom / multizone playback, master/slave, where this instance becomes the master)
- third: a new button next to the system / playlists button saying Join Playback Zone (with a popup of running xbmc instances), so one can join to a running instance in a differend room as a slave and making the remote instance the zone master.
The slave can always stop playback / escape the Zone by pressing the stop button.
Of course a full remote control an overview what is running now on any instance and options to join or leave a zone is much more sophisticated - but if the skinner-work is the issue - two small buttons and a context menu entry can almost do the trick in conjunction of a network discovery function.
Posts: 1
Joined: Jan 2012
Reputation:
0
Livin,
What solution do you go for in the end?
Posts: 152
Joined: Nov 2011
Reputation:
0
xbmcg
Senior Member
Posts: 152
Ah, ok.
Is this a 'classic' wired approach whith a central multi-zone matrix amp (or a PC with more than one audio card connected to separate amp's, wired to the speakers or to active speakers or something similar - so the "hub" is the PC and the spokes are just preamp / amplified outputs to the distributed Speakers?
Posts: 53
Joined: Jul 2012
Reputation:
0
2012-07-26, 01:18
VERY GOOD IDEA HERE!!
This may be more important/useful than many people realize. This is currently a huge selling point for Sonos systems in the market right now. The hub and spoke concept is the way to go here I agree. I have been testing many different systems and setups over the past 5 months and I must say that Sonos nailed this feature. It is simple to use and the mockup posted above is actually pretty close to what Sonos has created. Having the ability to drop wired or wireless audio points around the house and control them with clients through the main xbmc server is a feature that really lacks here. I have been reading a lot of forums from a few different solution providers and mainstream music listeners and audiophiles alike "DO" want this capability. I will start researching solutions if others can point me in the proper direction as far as what is needed for implementation on the XMBC side.
Thanks and great work to ALL, supporting this community!
). I swear, when I finish residency and go from being a slave to just very busy, I'll pick python back up and learn some real programming language and maybe actually help with xbmc (if not perfected by then) instead of just flicking ideas into the wilderness as if the devs are just sitting there waiting for inspiration. 
