-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multicast subscription (from other computer) not working on Linux #45
Comments
Thank you for getting back. I tried the following commits going all the way back (maybe random order here from my clipboard) 990e57d 9d45385 6f65111 dd59ce5 e5279e5 and none of them subscribed to a multicast stream from another computer. The second i run sACNView, i get data. The way i modified the code in BlenderDMX now works for me (i had to slightly modify it as i had a typo preventing it to work on Windows). I am testing with sACNView and MagicQ sending data from another Linux box, i also confirmed the non-subscribing issue when receiving sACN from gMA3 physical hardware being the sender. I am puzzled... :) |
I tried to reproduce your issue on two Windows 10 machines, but was not able to reproduce it. I was able to receive sACN packets via multicast. My setup were two machines running Windows 10, one as a receiver and one as the sender. Each running a short python script: first starting the receiver then the sender. I used the examples from the I also changed the sender from my Python script to sACNView for sending out data: same result. graph LR
subgraph sender
A(Win10 - Python script)
C(Win10 - sACNView)
end
subgraph receiver
B(Win10 - Python script)
D(Win10 - Python script)
end
A -->|multicast| B
C -->|multicast| D
Senderimport sacn
import time
sender = sacn.sACNsender()
sender.start()
sender.activate_output(1)
sender.activate_output(2)
sender[1].multicast = True
sender[2].multicast = True
sender.manual_flush = True # turning off the automatic sending of packets
sender[1].dmx_data = (1, 2, 3, 4) # some test DMX data
sender[2].dmx_data = (5, 6, 7, 8) # by the time we are here, the above data would be already send out,
# if manual_flush would be False. This could cause some jitter
# so instead we are flushing manual
time.sleep(1) # let the sender initialize itself
sender.flush()
sender.manual_flush = False # keep manual flush off as long as possible, because if it is on, the automatic
# sending of packets is turned off and that is not recommended
sender.stop() # stop sending out Receiverimport sacn
import time
# provide an IP-Address to bind to if you want to send multicast packets from a specific interface
receiver = sacn.sACNreceiver()
receiver.start() # start the receiving thread
# define a callback function
@receiver.listen_on('universe', universe=1) # listens on universe 1
def callback(packet): # packet type: sacn.DataPacket
print(packet.dmxData) # print the received DMX data
# optional: if multicast is desired, join with the universe number as parameter
receiver.join_multicast(1)
print("waiting...")
time.sleep(30) # receive for 10 seconds
print("waiting stopped!")
# optional: if multicast was previously joined
receiver.leave_multicast(1)
receiver.stop() Can you execute the same tests on your network and check, whether it works? |
Do note that i am specifically talking about Linux, not Windows. I have a bit of hard time testing all the cross-posibilities, but in one of my tests after several the sender from this sacn package was able to reach a receiver from this sacn package when testing between Linux machines. I say once, because the tests did not seem to be conclusive. In one direction it would seem to go correctly, in another direction not so, but then it would start working... again, starting sACNView always results in the data reaching the sacn package's receiver. As this sounded strange to me, i decided to re-test on gMA3 physical hardware again, with the same result - multicast receiving not working. To eliminate MA issue, i also tested on Avolites.... and sACN multicast from gMA3 and from Avolites Titan and both do not reach this sacn package's receiver unless:
This gives me 100% result every single time. |
OK, problem solved. This took quite a lot of testing. It turns out that default route must be present for the multicast to work, which is not compatible with ipv4 option "never default". So essentially this boiled to how the network link was configured and it now makes sense that using the link IP in the join multicast was basically providing direct routing. Sorry for the noise and thank you for looking into it. Hope this helps some future readers here. |
Thank you for the library, it is very useful! We use it in BlenderDMX.
All has been working for me perfectly when using a local sender, but i tested sender from another computer or a console and i can only receive data if i also start sACNView. This tells me that there is an issue with joining the multicast groups. I looked at wireshark, tried many different things and arrived at this:
i can make it working if i either use the multicast group IP address for socket bind - i actually use this technique when receiving PSN, but today i realized this only works if subscribing to a single group. Generally, PSN uses ports to distinguish sender, so it is not an issue there, but for sACN it is common to subscribe to multiple universes.
i can also make it working if the socket bind uses 0.0.0.0 and in the join_multicast, the actual network interface IP address is used. I have a working version here, i still need to test on Windows again, to be sure and i can try macOS in the future if time permits.
Would you be interested in me bringing it upstream? If the way i currently do this is not how you would prefer it, what would you suggest the best integration to the existing structure would be?
Thank you
The text was updated successfully, but these errors were encountered: