Mixed Port types in Xlights setup

[scuba]

I don't think this is a problem but I thought i'd check....

In my setup i've got 48 channels of LOR as number 1, followed by 50 universes using Multicast.  Due to a new mega tree,  I've added 8 universes using unicast (E682 controller).  If this will work it would save me time seting up the controllers that utilize multicast.  If not I'd have to change all the controllers to Unicast. 

Additionally, I use FPP to run the show... any issues with the mixed multicast and unicast setup?

[keithsw1111]

It’s not advisable but it will work.


Sent from my iPhone using Tapatalk

[scuba]

OK thanks.. Why not?

[keithsw1111]

Because multicast is pretty much broadcast on most home networks so every device gets hammered by all that data.


Sent from my iPhone using Tapatalk

[scuba]

I'm revisiting the Multicast vs unicast issue.  Based on the earlier discussion, mixed mode is not advisable.  So I went with all unicast with my 11 Sandevice controllers (E680 & E682) with 63 universes.  Are there any current issues with this approach? 

BTW: I thought I saw a post(a year ago?) that indicated a dropped controller (using unicast) would cause an issue.  Dropped controllers are not usually a problem with my setup, but I thought I run it to ground.

Thanks
John

[JonB256]

BTW: I thought I saw a post(a year ago?) that indicated a dropped controller (using unicast) would cause an issue.  Dropped controllers are not usually a problem with my setup, but I thought I run it to ground.

A dropped controller using Unicast will cause a lot of ARP packets (network speak for "where are you?").
If you are running output from a PC over a fast network, that probably won't be an issue.

It was an issue if sending your program output from a Pi or Beaglebone (FPP).
Note, I said "was"
Now, the latest FPP versions (v2.1) will cut off output to a non-responding controller, avoiding that flood of ARP packets.

[scuba]

thanks...I'm running 2.X on the V3 B+ Pi.  I should be ok

[Gilrock]

Now, the latest FPP versions (v2.1) will cut off output to a non-responding controller, avoiding that flood of ARP packets.

So if I have a circuit trip a breaker and a controller goes offline for a couple minutes while I reset the breaker does that mean FPP  will never recover and send data to that controller again?  Until when I reboot FPP?

[JonB256]

I dont know, Gil. Should be easy to test, though.

[Gilrock]

Yeah I might not upgrade until I know.  I might switch to xScheduler this year though.