I would think if panels are on the same output zone of the server they should mirror each other. For instance if you start browsing on one panel and then head o another room/panel you should be able to pick up where you left off in the other room.
If I were to write a module for this I would write it as JN described. This is how I've written other server modules and I'm a firm believer in only one GUI per dev regardless of the number of audio outputs and only one socket/module instance per audio output on that dev.
I would think if panels are on the same output zone of the server they should mirror each other. For instance if you start browsing on one panel and then head o another room/panel you should be able to pick up where you left off in the other room.
If I were to write a module for this I would write it as JN described. This is how I've written other server modules and I'm a firm believer in only one GUI per dev regardless of the number of audio outputs and only one socket/module instance per audio output on that dev.
I do the "Somebody else is controlling this zone. Do you want to play nice or kick their sorry butt off?" method myself.
Also, to echo previous pistol. Yes, I too use multiple IP ports. Until they change their protocol it's the only way.
Also, to echo previous pistol. Yes, I too use multiple IP ports. Until they change their protocol it's the only way.
Different IP dps per source output or per GUI x outputs? I've never played with one but if its the latter that would be a poorly designed protocol. It seems JN and crew have managed to do it so it's probably just a matter of time ($$) and the approach taken.
Yes, different IP D:P:S per control connection. Any IP connection can control any zone in the player. You chose what Zone (player instance) in a command.
The basic issue with their protocol is that a given telnet connection can only control/get feedback from only one zone at a time. It does, however, support multiple telnet sessions on the same port simultaneously.
I've spoken at length with their engineering and have had not much luck getting this concept across. I explains that the easy way to implement this is to just prefix every return with a zone ID tag and just send everything down one pipe. Similar on commands coming in;just prefix them with the zone ID.
The basic issue with their protocol is that a given telnet connection can only control/get feedback from only one zone at a time. It does, however, support multiple telnet sessions on the same port simultaneously.
I've spoken at length with their engineering and have had not much luck getting this concept across. I explains that the easy way to implement this is to just prefix every return with a zone ID tag and just send everything down one pipe. Similar on commands coming in;just prefix them with the zone ID.
So, until that time you have to burn 5 IP ports.
That's not bad, 5 ports for 5 outputs and 5 instances of a module, that's what I would expect. I thought earlier in this thread it was suggested a port per UI x the number of outputs, that would be absurd.
The reason that we do one socket per UI is that browsing is instanced per socket by the MMS. Multiple panels browsing on the same socket would mirror each other if they were all on the browsing screen. We find that to be a less-desired mode of operation. In our implementation, multiple panels are free to browse at will. Once one of the panels makes a selection, only the "Now Playing" feedback of the other panels changes. The browsing of the other panels is not interrupted.
I can understand that this would give the appearance of more independent usage at more UI's, but the reality comes when you are digging around setting up your selections and someone beats you to the PLAY NOW button on some other panel, taking you by surprise and overruling your plans. But I can see how some would prefer independent browsing, even if they are sharing the results.
We prefer to let UI's that are sharing the output also share the state of the selecting/guide feedback. The users might even be cooperating in the process.
The panels might be sharing the output in the same room... or in different rooms. When more than one ROOM is attached to any given source, we put up a SHARING flag on all involved UI's as well, so the user has awareness that they might be in a control fight.
This lessens the number of these support calls:
Him (on phone): Tivo's broken again. Every time I dial a channel, it changes back.
Her (in background): Yeah, that's happening to me too.
I've spoken at length with their engineering and have had not much luck getting this concept across.
Ha! I have had exactly the same conversations. I am quite confident it will not be changed.
Further, Autonomic is absolutely, positively, beyond the shadow-of-a-doubt the most poorly documented product geared toward the custom integration market. I mentioned that to them as well. They didn't seem to care about that either.
That's not bad, 5 ports for 5 outputs and 5 instances of a module, that's what I would expect. I thought earlier in this thread it was suggested a port per UI x the number of outputs, that would be absurd.
Vining,
To be accurate my module is 5 ports, one module instance and up to whatever many UIs.
As of about 2015 the modules that Autonomic wrote for AMX were very poor. The modules were based on an AMX - Windows Media Control Center implementation from around 2006. Autonomic wouldn't make any commitment to improve them. Unfortunately, my business owner jumped the gun -again- and purchased several MMS units to deploy without consulting me first about the state of the modules, because he heard that modules existed and his information was always better than anybody else's. Once again I got stuck writing modules for a media server, which is a huge pain in the ass. It took about a month. I got something about 98% reliable before getting yanked away to work on some other poorly thought-out implementation.
Once I got past that, I was faced with the usual dilemma about the number of COMM & UI modules to use. Here again, media servers are the worst, as the number of COMM & UI modules blows-up memory when you have four dozen touch panels in the system, assuming one COMM & one UI module per touchpanel. Takes forever for the Netlinx controller to boot. Another problem is the sheer amount of network traffic created when modules communicate to dozens of touchpanels at the same time, even when the touchpanel isn't controlling the device.
So, here's the practice that I adopted that works very well: First, drop the assumption requiring that every touchpanel must have it's own browse context. Everybody accessing the same DSS or Bluray player uses the same OSD. Media servers can use the same UI module for all touchpanels controlling a particular zone. Next, COMBINE_DEVICES. Create a virtual touch panel that corresponds to each UI module. When a touchpanel needs access to the UI module, COMBINE_DEVICES. When the touchpanel no longer needs access to the UI module, UNCOMBINE_DEVICES, then rebuild the COMBINE_DEVICES with the reduced list of touch panels. This has the benefit of not broadcasting all UI info to all touchpanels at all times as well as keeping the number of COMM and UI modules reasonable.
My boss the idiot had a 5 zone Mirage, a 2 zone ReQuest, 5 ReQuest IMCs, 8 iPod docks, 8 DSS receivers, 8 Bluray players, 4 Sirius/XM/AM/FM tuners, 2 Apple TVs, 4 Rokus, 8 Chromecasts being controlled by 49 user interfaces (9 user interface types), plus the usual lighting, security, pool/spa, motorized window shades, HVAC zones, etc. There were so many UI & COMM modules that the system couldn't boot. The interpreter just gave up. Splitting the program across multiple Netlinx controllers just made the problem worse. Once I implemented the COMBINE_DEVICES methodology, it brought the program back under control. Barely. Nothing could get the business owner under control.
Comments
If I were to write a module for this I would write it as JN described. This is how I've written other server modules and I'm a firm believer in only one GUI per dev regardless of the number of audio outputs and only one socket/module instance per audio output on that dev.
I do the "Somebody else is controlling this zone. Do you want to play nice or kick their sorry butt off?" method myself.
Also, to echo previous pistol. Yes, I too use multiple IP ports. Until they change their protocol it's the only way.
Yes ports for zone control.
The basic issue with their protocol is that a given telnet connection can only control/get feedback from only one zone at a time. It does, however, support multiple telnet sessions on the same port simultaneously.
I've spoken at length with their engineering and have had not much luck getting this concept across. I explains that the easy way to implement this is to just prefix every return with a zone ID tag and just send everything down one pipe. Similar on commands coming in;just prefix them with the zone ID.
So, until that time you have to burn 5 IP ports.
That's not bad, 5 ports for 5 outputs and 5 instances of a module, that's what I would expect. I thought earlier in this thread it was suggested a port per UI x the number of outputs, that would be absurd.
I can understand that this would give the appearance of more independent usage at more UI's, but the reality comes when you are digging around setting up your selections and someone beats you to the PLAY NOW button on some other panel, taking you by surprise and overruling your plans. But I can see how some would prefer independent browsing, even if they are sharing the results.
We prefer to let UI's that are sharing the output also share the state of the selecting/guide feedback. The users might even be cooperating in the process.
The panels might be sharing the output in the same room... or in different rooms. When more than one ROOM is attached to any given source, we put up a SHARING flag on all involved UI's as well, so the user has awareness that they might be in a control fight.
This lessens the number of these support calls:
Him (on phone): Tivo's broken again. Every time I dial a channel, it changes back.
Her (in background): Yeah, that's happening to me too.
Ha! I have had exactly the same conversations. I am quite confident it will not be changed.
Further, Autonomic is absolutely, positively, beyond the shadow-of-a-doubt the most poorly documented product geared toward the custom integration market. I mentioned that to them as well. They didn't seem to care about that either.
Vining,
To be accurate my module is 5 ports, one module instance and up to whatever many UIs.
As of about 2015 the modules that Autonomic wrote for AMX were very poor. The modules were based on an AMX - Windows Media Control Center implementation from around 2006. Autonomic wouldn't make any commitment to improve them. Unfortunately, my business owner jumped the gun -again- and purchased several MMS units to deploy without consulting me first about the state of the modules, because he heard that modules existed and his information was always better than anybody else's. Once again I got stuck writing modules for a media server, which is a huge pain in the ass. It took about a month. I got something about 98% reliable before getting yanked away to work on some other poorly thought-out implementation.
Once I got past that, I was faced with the usual dilemma about the number of COMM & UI modules to use. Here again, media servers are the worst, as the number of COMM & UI modules blows-up memory when you have four dozen touch panels in the system, assuming one COMM & one UI module per touchpanel. Takes forever for the Netlinx controller to boot. Another problem is the sheer amount of network traffic created when modules communicate to dozens of touchpanels at the same time, even when the touchpanel isn't controlling the device.
So, here's the practice that I adopted that works very well: First, drop the assumption requiring that every touchpanel must have it's own browse context. Everybody accessing the same DSS or Bluray player uses the same OSD. Media servers can use the same UI module for all touchpanels controlling a particular zone. Next, COMBINE_DEVICES. Create a virtual touch panel that corresponds to each UI module. When a touchpanel needs access to the UI module, COMBINE_DEVICES. When the touchpanel no longer needs access to the UI module, UNCOMBINE_DEVICES, then rebuild the COMBINE_DEVICES with the reduced list of touch panels. This has the benefit of not broadcasting all UI info to all touchpanels at all times as well as keeping the number of COMM and UI modules reasonable.
My boss the idiot had a 5 zone Mirage, a 2 zone ReQuest, 5 ReQuest IMCs, 8 iPod docks, 8 DSS receivers, 8 Bluray players, 4 Sirius/XM/AM/FM tuners, 2 Apple TVs, 4 Rokus, 8 Chromecasts being controlled by 49 user interfaces (9 user interface types), plus the usual lighting, security, pool/spa, motorized window shades, HVAC zones, etc. There were so many UI & COMM modules that the system couldn't boot. The interpreter just gave up. Splitting the program across multiple Netlinx controllers just made the problem worse. Once I implemented the COMBINE_DEVICES methodology, it brought the program back under control. Barely. Nothing could get the business owner under control.