QLab OSC & EOS Ti missing cues

kiilljoy

Member
We are running projection cues for our current show from QLab (Ver 4.5.2) triggered over OSC from an Eos Ti (ver 2.9.0 Build 77). Qlab is running on one of the older trashcan Macs, and it's hooked into the lighting control network. I have the wifi remote running on the second of the Ti's network ports. We started the run by using the ETC OSCRouter, but after digging into the EOS updates, I've since switched the trigger over to the native translation in the EOS options. I've had the same problem with both setups.

The problem is that, occasionally, OSC will not trigger this one specific cue in Qlab. This particular design is not very cue heavy, so right before the problem cue there's a break of about 9 minutes. All of the other 10 or so cues have, so far (6 weeks, 6-8 shows per week), have fired just fine. I haven't done any experimentation (and I don't have much time as the show is leaving my space on Sunday) since I just had this thought, but could it be that there's a network timeout somewhere in the chain? Has anyone had an experience like this? Are there any vital pieces of information I've left out that would help point to an answer?

There is probably close to 200' of Cat5 and two unmanaged switches in between the console and the Mac. My movers and LED are also feeding from this data line (There's a ETC DMX Gateway also connected to the second of the switches).
 
It is. OSC works over both, and eos and qlab support both transmission methods. This is likely your issue, it sounds a lot like normal UDP behavior to me.
I see it. I'll look into it for next time. It's just weird to me that the misfire is only ever on one particular cue.
 
Some network switches have IEEE ports that have energy efficiency turned on. If traffic goes quiet for a while, the ports clamp off and wake back up when they see traffic. In a UDP situation, packets only fire in one direction without verification they got where they were going. Faster than TCP traffic but it means if a port falls asleep you could be dropping packets.

You could try replacing the switches or sending a dummy cue 10-20 seconds before the real cue to make sure the ports are awake. No guarantees this will solve your problem but it's worth a try.
 
Some network switches have IEEE ports that have energy efficiency turned on. If traffic goes quiet for a while, the ports clamp off and wake back up when they see traffic. In a UDP situation, packets only fire in one direction without verification they got where they were going. Faster than TCP traffic but it means if a port falls asleep you could be dropping packets.

You could try replacing the switches or sending a dummy cue 10-20 seconds before the real cue to make sure the ports are awake. No guarantees this will solve your problem but it's worth a try.

I thought about this--but if sACN data is being sent over the same connection, I don't think the mac is smart enough to know that the traffic is not for it, especially with unmanaged switches where multicast subscriptions are likely ignored.
 

Users who are viewing this thread

Back