Poss. bug 2.7.2 sACN viewer

i don't see that here.
that's what i tried: i have a computer with sACNview 2.0.1 and i'm looking at universe 7. on eos i open tab 37, select a fixture in universe 7. i can see the values in tab 37. i run the intensity wheel up and down and i can see the changes in sACNview.

this was a Ti which is primary, there are also 2 nomad clients and a Ti backup in the system.

if this i as the same what you did, maybe there is a piece missing in the reproducer...

When I say 'lose control', I mean physical control of the rig. The values change on screen, as you have experienced, but none of the fixtures respond to the changes until either the sACNview tab is closed, or I change the sampled universe. Once this happens, the fixtures catch up to the commands given whilst the viewer was open

I was checking the changes on another computer with the software sACNview. So yes, Eos was still sending values, while tab 37 was open

Following up on this problem (I am in the same venue where this problem occurred). Through troubleshooting we have found the problem.

The culprit was the network switches we were using. Whenever we connect 2 TP-Link Gigabit Desktop Switches, the output of the universe that we are sampling with the sACN window freezes.

To replicate, I connected two LED PARS to two separate ports on a 4 port node that is connected to the console via 2 of the above switches. Then patched them to two separate universes.
-Set them both running a basic intensity effect.
-Open the sACN sampling window and sample the universe of one of the fixtures. The effect on the fixture will freeze even though the sampling screen will still have moving values.
-Change to the universe of the other fixture and the effect on that fixture will freeze and the first one will resume it's effect.
-Close the sACN window, and both will resume their effect.

If there is only one switch between the console and the node, the problem doesn't replicate.
When we replaced the second switch with a domestic router, the problem doesn't replicate.

So our first solution of 'Don't open the window', has now been replaced with 'Buy better switches'.

However we do find it interesting that while we thought it was a network being flooded with too much back and forth info when doing sACN monitoring, it was still only one universe that is being affected, not the entire node.

Hope this helps.

This is interesting. Can you post the model number of the TP-Link switches and details of any configuration settings if they are managed switches?

There is a probable explanations of what is going on, but its a bit of an Interesting/challenging one.

Its probable that the sACN monitoring window is doing that by acting as an sACN subscriber at actual IP level (rather than grabbing the output higher up the code stack).

sACN is probably being sent multicast over IP.

Once upon a time we used hubs rather than switches and in fact IP was designed around hubs (really to be historically accurate actually radio broadcast transmission), where everything on your local network segment is sent to every device. The device then has a filter in it at hardware level to only respond to packets sent to its mac addresses or to packets marked broadcast. The IP address of a device gets mapped to the mac address using ARP requests. This means the processor in the device only gets interrupted by packets of data that actually are for the device.

What's not always fully understood about multicast is that actually like the above it would still go to all the devices but it has a kind of fake mac address that is made up of a standard prefix and the group (ie the last 23 bits of IP address in the 224.x.x.x - 239.x.x.x range).

sACN agrees a group number with the devices it wants to multicast to and then sends to that dummy mac address and the devices that have subscribed pick it up.

All good so far if we are using an old hub, but when switches came along they start doing smarter things to allow several devices to talk to each other totally simultaneously on the local net. They do that by working out from the mac addresses which connection to switch the signal down.

That's straight forward for normal IP but multicast becomes a bit more problematic as the switch doesn't know about what things the device on the other end of wire has subscribed to. So simple switches just send any multicast down all cables and allow the original design of IP multicast to sort it out at the device.

However smarter switches do something devious. We all know there are TCP and UDP packets on an IP network and we may have come across ICMP (ip control protocol - what you are using when ping something) but there is another low level packet type that we might think was a typo IGMP which control the setup of the multicast groups. The smarter switches do something call IGMP snooping, which is basically spying on the network traffic and looking at the IGMP negotiations between devices, from which they can deduce what multicast groups things are listening to on the end of each of their wires and then only send the multicast down those wires.

So back to the sACN viewer issue. What is probably happening when the switches are cascaded are they are not correctly working out things from the IGMP and when they see the IGMP traffic created by the sACN viewer connecting, they end up incorrectly assuming they dont need to pass on the traffic to the other devices that want it. When it disconnects they resume.

All pretty devious and unexpected.

The solution counter intuitively is (as with a lot of network connectivity issues in lighting) to use cheaper lower spec switches - not as you were suggesting 'Buy better switches'.

Ironically almost all the network connectivity issue that are logged on this forum are due to smarter more expensive network switches. As you noted using a "domestic router, the problem doesn't replicate". It kind of makes sense as the better devices have a lot of optimisation in them for heavy bandwith usage - streaming video, large data volumes etc. so they try hard not to send data anywhere its not actually needed, whereas in lighting we are at trivial levels of bandwidths 250Kbits for a single universe but we definitely dont want it randomly blocked by something being smart.

Hope that makes sense to someone

We were using a TL-SG108 and a TL-SG105. Both unmanaged switches.

Whilst they are unmanaged switches they do have a config option by the look of it to turn on IGMP snooping (the option to spy on IGMP traffic to determine how the multicast needs to flow).

You may well find toggling that option fixes your problem (eg it may actually need to be off for example to make the switches dumb enough to work)

www.tp-link.com/.../faq-1125.html the first screenshot in that article relates to your switch the others to upstream managed switches, and whilst its an IPTV example the principle is similar.

I just ran into this same bug running on 2.7.3 Build 10!

I've been running Ubiquiti Unifi Switches on set, and noticed that I would occasionally lose control of whole universes. So during my troubleshooting, I grabbed an unmanaged TP-LINK 5-port gigabit switch (TL-SG105) and did a small-scale test which was just the Ion Console -> Switch -> Laptop running an sACN viewer. You can clearly see the issue demonstrated here:

https://www.youtube.com/watch?v=M6uSIdR8rgw

Definitely worrisome! Clearly this model switch doesn't like the way the console's sACN Viewer handles itself, but this issue makes me cautious of any switch or router I have in the system.