Closed Bug 905330 Opened 11 years ago Closed 11 years ago

Second IPad Control Channel Unusable in SFO152 Commons

Categories

(Air Mozilla :: Crestron, defect, P1)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: richard, Unassigned)

References

Details

The two channels (41790 and 41792) of iPad control for SFO Commons were intended to allow independent control of various room functions.  However the two devices interact in a multitude of bizarre ways.  Here's one example:

Connect the primary iPad to the Commons - #1 channel (41790)
Connect the second  iPad to the Commons - #2 channel (41792)

On the second iPad Select Presentation Mode.

On the primary iPad Select Video Conference Mode, then select Room Search.

The Room Search dialog appears behind the Presentation Menu on the second iPad.
Closing on the second iPad also closes it on the primary iPad.

Then preses Video Conference on the second iPad.  This changes the primary iPad to Presentation Mode.   

Pressing the Room Search button on the secondary iPad does not open the search window on that iPad... but switching the primary iPad to Video Conference mode opens that mode with the Room search page open, and switches the secondary iPad to Presentation Mode with the Room Search page behind the Presentation switching mode.

Clear as mud, I know....   Let's just say the secondary iPad control isn't usable.
I get it - we'll need to take a look at the user mode interaction.

The way this is intended to work is that the user modes are locked together all the time (Video Call > Room Search on one panel = the same on the other) - only the Advanced modes should operate independently.

So you can get into Advanced on one panel while a user is in progress on the other, but both can have separate instances of Advanced mode running at the same time - so one iPad can be on "Audio" while the other is on "Routing".

I'll compare the two instances in the program and see if there are any disparities.  We should have VPN access up soon so I can push that remotely if we know the room's not in use.
I've already figured out what's causing this: programmer error :)

When I re-ordered all the user mode buttons to get Video Conference first, etc. I neglected to match up the 41792 programming.  They now match and I have a file I can load to solve this.

If we get our account to log into VPN soon I can push this after-hours and it can be tested next time someone's using the room.  Otherwise, I can stop in to load this at some point soon.
This is fixed.  New program uploaded today.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.