Hey, so I'm sure there are a bunch of questions about this but I can't seem to find them. Is there an online client for OSX? I can always run parallells but it'd be nice to run it natively. Also, is the windows version compatible over a wireless network? Other MEs have tried to make it work and have not been successful so far.
Thanks!
Jeff
This question comes up often. Please read what Tracy from tech services has to say. Also there is a ton of post under the networking section related to wireless connections.
I've posted on this before, so please forgive me if this is redundant for anyone:
This may work, or it may not. It breaks down into a question of how large your show is, what networking protocols you have running on the network, the technology of your wireless access point, and the general RF environment.
Wireless Access Points (WAPs) work best when traffic is relatively slow or moves in bursts. Common wireless traffic is for applications like email or web browsing, where delays are natural and constant transmission is not required. Applications that display streaming video cover network delays by downloading and buffering the stream ahead of the currently displayed frames. Eos/Ion/Element clients/RVIs do not have this luxury, since their displays are updated in real-time. Many lower-end access points simply cannot handle the continuous high speed of traffic. The typical symptom of an overworked access point is a client that starts the show transfer process but stops partway through -- often repeatedly.
Using networks with proper wireless coverage and little radio interference, we have found keys for good client/RVI operation include: minimizing the unnecessary traffic running over the WAP, and using a WAP that can handle the remaining traffic relatively smoothly. We have found the Cisco 1100 and 1200 series WAPs (often with a filtering device like a custom configured managed switch before them) seem to perform acceptably in some situations.
Lacking a higher end access point like one of the Ciscos above, I have once succeeded in getting wireless client working from an Ion system over a typical Linksys WP54g. That particular system did not use EDMX or sACN (only hard-line DMX from the console) so we were able to turn off both of those protocols in the console shell. Removing that traffic allowed the client to eventually transfer the show file and sync up.
I've also heard of some people who used the latest 802.11n Apple Airport Extreme and reported success while still using one of the network protocols (don't know if it was EDMX or sACN). I would recommend turning off any output protocols (EDMX or sACN) you aren't using in this scenario.
To be very clear about this though, this issue affects client pcs and RVIs because they are also transferring all of the show synchronization data. We haven't seen these same issues with iRFR. In our experience that seems to run fine over a properly configured consumer grade WAP.
Hope this helps
P-
Jeff
This question comes up often. Please read what Tracy from tech services has to say. Also there is a ton of post under the networking section related to wireless connections.
I've posted on this before, so please forgive me if this is redundant for anyone:
This may work, or it may not. It breaks down into a question of how large your show is, what networking protocols you have running on the network, the technology of your wireless access point, and the general RF environment.
Wireless Access Points (WAPs) work best when traffic is relatively slow or moves in bursts. Common wireless traffic is for applications like email or web browsing, where delays are natural and constant transmission is not required. Applications that display streaming video cover network delays by downloading and buffering the stream ahead of the currently displayed frames. Eos/Ion/Element clients/RVIs do not have this luxury, since their displays are updated in real-time. Many lower-end access points simply cannot handle the continuous high speed of traffic. The typical symptom of an overworked access point is a client that starts the show transfer process but stops partway through -- often repeatedly.
Using networks with proper wireless coverage and little radio interference, we have found keys for good client/RVI operation include: minimizing the unnecessary traffic running over the WAP, and using a WAP that can handle the remaining traffic relatively smoothly. We have found the Cisco 1100 and 1200 series WAPs (often with a filtering device like a custom configured managed switch before them) seem to perform acceptably in some situations.
Lacking a higher end access point like one of the Ciscos above, I have once succeeded in getting wireless client working from an Ion system over a typical Linksys WP54g. That particular system did not use EDMX or sACN (only hard-line DMX from the console) so we were able to turn off both of those protocols in the console shell. Removing that traffic allowed the client to eventually transfer the show file and sync up.
I've also heard of some people who used the latest 802.11n Apple Airport Extreme and reported success while still using one of the network protocols (don't know if it was EDMX or sACN). I would recommend turning off any output protocols (EDMX or sACN) you aren't using in this scenario.
To be very clear about this though, this issue affects client pcs and RVIs because they are also transferring all of the show synchronization data. We haven't seen these same issues with iRFR. In our experience that seems to run fine over a properly configured consumer grade WAP.
Hope this helps
P-
