[BUG] Beam Sender Filters do not work

[icefire555]

Describe the bug
When I'm setting up beam, the available beam feeds never shows any items listed. However if I manually set a port and IP it works ONLY on the main beam output.

Beam Sender Filters don't work.*

And Beam will not function on a secondary Nic. This is a special configuration where it's a direct Pc to Pc connection without a router. I can get connections between the 2 PCs like ping. I also was able to use VoiceMeter VBAN over it without any problems. I am doing this to isolate possible network issues causing UDP packet order issues.

To Reproduce
Steps to reproduce the behavior:
If I setup beam for the entire OBS session by going to Tools > Beam Output Settings > enable the beam sender output > and set a manual network interface and port.
Then configure this on the other side, the receiver never sees an available feed. However, if I set the IP and port it works.

This does not work on Beam Sender Filters and I cannot get them working. (I am giving each sender its own port.)

Also If I enabled a second network interface. Even if the main output it set the same was it was working mentioned above. It stops working.

Expected behavior
I expect that beam would see the sessions coming in.

Screenshots
Main Sender

Sender Filter

Receiver

Receiver Filter

Audio showing up on the reciever for main sender.

Logs and details about your system
Sender Log
https://obsproject.com/logs/KG5665hOvNotKUq4

Receivers Log
https://obsproject.com/logs/eicmKk4O5Z1WC9eF

Then post the links to this log here.

If you encountered a crash, please upload a crash log too (after restarting OBS):
No Crashing occurred

Expect that it will be hard or even impossible to help with your issue without these logs. If, for some reason, you really are unable to provide them, at least this information is necessary that would otherwise have been contained in the logs:

• Windows 11
  

• OBS version
  V31.0.0 and 31.0.0 Beta3 Enhanced Broadcasting v39 on receiver

• Beam version ("latest" is not a valid version, please specify the exact version number)
  Latest Version per last update in July 10th

• OBS video settings (resolution, FPS, color settings...)
  Canvas 4k, output 1440p

• if you're using a network, how do you connect the computers involved, Ethernet (1G? 2.5? 5? 10?), or Wi-Fi, Thunderbolt Network?
  +Main network is (192.168.0.1/22)
  Sender <-> 25g <-> Router <-> 10g <-> Switch <-> 2.5g <-> Thunderbolt USB Adapter <->Receiver
  (I have tried the hardwired 1g network port on the Receiver as well and had the same problems.)
  +Secondary Network is (192.168.250.1-2)
  Sender <-> 1g <-> Receiver
  Windows firewall is set to allow all connections on all ports from these IPs.

Additional context
When I was setting up Voicemeter VBAN I had out of order UDP packet issues. So I suspect latency on my network for beam is caused by that. And it's why I'm setting up the direct connection. Vban worked over the direct connection without issues.

I also was having a latency issue with Teleport and was suggested Beam from that thread.
fzwoch/obs-teleport#107

[icefire555]

While writing this, the sender filter started working. But only in the technical sense. Look at this latency. I suspect it's caused by network issues.

The Master Output seems to be pretty steady

[icefire555]

It appears the issue with the second nic was that beam receiver is requesting the feed from the sender and I didn't add a firewall rule inbound on the sender pc to account for that.

This did not fix the issue of the Available Beam Feeds populating tough. I also have horrible delay increase on only the receiver feeds. The main feed doesn't have issues and is staying at a constant 0ms/66ms delay.

Also the direct 1gb network does not fix the issue. But I do see audio come though.

So the current problems are:
-'Available Beam Feeds' doesn't populate
-Render Delay Limit is unusable on any filter beam senders.
+This is because they will count up to 1s of lag over the timespan of 6s. And this happens on an optimal network with no network filtering or routing. I tried giving it a frame buffer and no buffer.

[YorVeX]

If troubleshooting anything related to network connections, please always entirely disable any firewalls on both sides. Otherwise you risk investing lots of time hunting down issues in a piece of software or network setup, that have been caused by the firewall the whole time.

Only at the end when everything works as desired, enable it again - and if then issues occur you didn't have before, you know that it's caused by the firewall and you can separately troubleshoot this.

if even necessary, most people are running software firewalls behind routers that already firewall them from the Internet even better than the software firewall ever could, making them add nothing but introduce potential problems.

[icefire555]

Do you think Beam would need a Windows Firewall rule which allows more than all ports in and outbound from the other systems' IPs?

Sender/Game Pc (This is inbound but I have the same setup for outbound)

Receiver/Steam Pc

[YorVeX]

Firewall troubleshooting is really out of scope for me, troubleshooting Beam by itself on a more complex network can be hard enough as it is 😛

Just one small example so that we get on topic here: Beam is using Multicast to discover feeds. Many firewalls just block Multicast packets (or specifically broadcasts) and it's often not obvious that they do, not obvious how to stop that and sometimes there's not even an option for it at all. It's almost certainly not covered by allowing the IPs that you configured there.

That's in addition to some network switches just not forwarding these packets (not even for security reasons, just a missing feature, they simply can't handle these packets) or routers also blocking them, especially (but not limited to) when WiFi is involved.

The discovery itself is actually super simple. A Beam client sends a broadcast through the network on all interfaces, that says "anyone out there offering Beam feeds?". All potential senders are listening for such broadcasts and if they get one, respond using Unicast to that receiver with the feed that they offer and on which IP and port.

That's all there is, can't really do any more detailed debugging there - if discovery fails, something in your network is swallowing these packets. If you want to actually see this on full detail level, you can run OBS in --verbose mode, then Beam will log all Multicast packets it's sending and receiving (and other useful things), just search the log for "Discovery" after you ran a verbose session. Or keep the OBS live log window open while opening the properties of a Beam receiver, that's the moment it's sending the broadcast.

NDI and Teleport do it the other way round by the way: there all senders are every few seconds broadcasting the feeds that they offer and clients just pick that up. Depending on in which direction Multicast packets get lost, you can have situations where Beam discovery works but not Teleport/NDI, or vice versa, or both don't work if it's blocked in both directions.

The reason I did it differently in Beam is that I didn't like the idea of having senders constantly spam the network in the background (while the packets itself are small, broadcasts basically keep every single component and computer in your network busy receiving and processing them, which is exactly why most firewalls block it by default), although discovery usually is only needed once during startup or initial connection.
Unlike the others, an inactive Beam source is really doing nothing, while the others constantly broadcast and the receivers maintain feed lists in the background even if the respective sources aren't visible.

But seeing how often it's becoming a problem, I thought about at least giving an option to let Beam also do it as Teleport and NDI are doing in addition, that way the chance is increased that discovery works unless it's really blocked in both directions.