Multicast Universe inputs don't ever start if not found when FPPD starts

[Jchuchla]

FPP Version and Hardware: FPP v5.3.1 (v5.3 branch) Running on Kulp F8-PB

Describe the bug and Steps to reproduce: The FPP instance is operating in player mode, but configured as a bridge. Multiple e1.31 multicast universes defined as inputs. The FPP will come up and not be receiving any data until I restart FPPD. This setup is using a managed switch network with multiple switches and IGMP snooping properly configured. There are multiple managed switches between the e1.31 source and the FPP destination.

This seems to happen whenever I have a whole house power failure. FPP boots much faster than my network switches. The multicast groups won't be available on the network when FPP first starts up. I believe that restarting FPPD causes the FPP to send IGMP subscription requests and

Expected behavior: If this indeed caused by my suspected IGMP subscription suspicion above, FPP should periodically send IGMP subscription requests if it's not receiving data when multicast inputs are defined.

Additional context: Switches involved Cisco SG350, Cisco SG200, Netgear GS108T

FPP_Logs_20211121.0038.zip

[darylc]

Have you tried the fpp boot delay setting? FPP Settings->System->FPPD Boot Delay

"The time that FPP waits after system boot up to start fppd. For environments that are powered down regularly, fppd may start up quicker than the network environment fully starts up which may cause E1.31 multicast to not work properly. Setting a Boot Delay will cause fppd to wait 'X' number of seconds to start which can give the network switches and routers time to fully start up."

[ghormann]

Closing as no reply from OP

[Jchuchla]

I must have missed the notification a few weeks ago. Please reopen, it is not fixed. I ran into this issue again just a few days ago.
The boot delay may be a temporary band-aid but it is not really a solution to this issue. It would just make FPP take longer to boot all the time. It also wouldn't solve the issue where an upstream switch reboots without FPP rebooting. The switch would never get a new subscription from the FPP when the switch becomes available again.

[Jchuchla]

A better solution would be to constantly monitor the configured multicast universes for whether they're actively receiving data, If no data for a few seconds, then send a new subscription.
In theory, if the IGMP system is working properly on the network, FPP would simply need to respond appropriately whenever it receives a membership query from the switch/mrouter. The switch should send such a query when a new multicast stream is available, and then periodically thereafter. But there's plenty of real-world cases where that doesn't actually happen. So the gratuitous subscription solution is often a more reliable implementation. Just periodically (every 30-60 seconds) send the membership report even if not asked for it.

[Jchuchla]

I just had this issue happen again today after a power outage. The FPP was up and running. It was sending sACN out its port. But there were no multicast groups registered on the switch. The switch wasn't fully booted yet when FPP came online.

The boot delay option is not a viable solution for this. The time for the network to resume is nondeterministic. You can't specify a decent time that will be long enough without being excessively long. It might be 4 minutes, it might be 15.

The better solution would be to wait for the network to be ready and then start all the services that need it. This could be a menu option "wait for network" so that it doesn't break other's existing installations.

Another potential solution would be to have a service periodically monitor the IGMP groups that it's it knows it's sending. If the groups that it knows it's sending aren't registered on the switch, then resend the registration.

[darylc]

Feel free to contribute a fix, this is a very unique configuration and thus unlikely to get attention in 2024.