OSC via TCP

321 views
Skip to first unread message

googl...@sorenknud.dk

unread,
Jan 14, 2016, 4:26:59 PM1/14/16
to QLab
Hi :)

I have some issues with random OSC dropouts on a show (from a mac mini running Qlab to a mac pro also running Qlab) and I will enable logging from now on on both machines to see what is happening. I'll setup wireshark also.

Its sometimes multiple cues at once, but less than 4 at the time.

There is only a Cisco SG-200 8p and 30 feet of cat6 inbetween the two computers, and most of the time there are no issues.


Can I choose weather I send via UDP or TCP? Would be nice to test with TCP (theese are cues that should rather fire for certain with a little delay, than not fire at all).



Best

Soren

Chris Ashworth

unread,
Jan 15, 2016, 2:50:08 PM1/15/16
to googl...@sorenknud.dk, ql...@googlegroups.com
Hi Soren,

At the moment, it is not possible for an OSC cue to connect via TCP; they send out via UDP only.

In my experience it’s very unusual for a simple closed network to drop UDP packets like that. If you turn on log level 2 you can see a record of all incoming OSC messages to help with troubleshooting.

Are theses outgoing OSC messages happening nearly simultaneously or is there significant time between different messages?

-C

Andy Lang

unread,
Jan 15, 2016, 3:09:14 PM1/15/16
to ql...@googlegroups.com

On Thu, Jan 14, 2016 at 4:27 PM googl...@sorenknud.dk wrote:

There is only a Cisco SG-200 8p and 30 feet of cat6 inbetween the two computers, and most of the time there are no issues.

In addition to Chris’s suggestion to go to log level 2 and see what is actually being received (or not) by QLab, I’d look into how the switch is configured. The SG200 is a “smart” or semi-managed switch, so for a show-critical network, you need to go through and make sure things like Green Ethernet/802.3az/EEE (Energy Efficient Ethernet) are disabled. These settings among other things, can wreak havoc with show networks, and are often enabled by default on these so-called “smart” switches.

I'd also take a look at any of the DOS prevention settings, which can sometimes mistake friendly-fire for packet storms, as well as ensuring that any QoS settings in that switch are set properly.

-Andy


Andy Lang
@SoundGuyAndy
sup...@figure53.com

Reply all
Reply to author
Forward
0 new messages