Setting a FPP Controller to "xLights Only" Disables E1.31 Input #2648
Comments
|
My understanding is "xLights Only" is intended for FPP remote devices. The FPP remote device should not respond to E131 packets. This is why it disables the E131 inputs. |
|
I understand that. To add, this setting is also utilized by fpp connect so
that other fpp devices will never send e131 data to a fpp device set as
xlights only. If the channel inputs are just gonna be disabled upon
provisioning then why provision the inputs at all?
Given the name of the setting that would be my expected use case.
* it will still listen for e131 data [from xlights]. I realize this is all
or nothing.
* FPP connect will honor honor this setting when provisioning channel
outputs of other FPP devices.
With the setting as it is currently there is different behavior between DDP
and e131 when testing from xlights. This is because there isnt a disable
option for DDP packets as FPP is always listening. Fpp connect does honor
this flag for not enabling the channel outputs.
For the e131 and xlights only it seems kinda like belt and suspenders.
…On Tue, May 18, 2021, 12:18 PM Scott H. ***@***.***> wrote:
My understanding is "xLights Only" is intended for FPP remote devices. The
FPP remote device should not respond to E131 packets. This is why it
disables the E131 inputs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2648 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4XLQHPZ3OV444HMSDFNA3TOKOMTANCNFSM45BIG2ZQ>
.
|
|
I'm not saying this is not a bug, but the STRONG STRONG recommendation is to use DDP to send data from xLights to FPP. I would recommend switching the configuration from e1.31 to DDP. The recommended configuration works so this bug would definitely be considered very low priority. |
|
Understood. The only reason I ran across this is I was actually going the
opposite direction (DDP > e1.31) because I got tired of chasing channels
whenever I made a change to one of my FPP based controllers higher in the
list. With e1.31 I could assign a start universe so the theory was that
changed made on controller X don't import controller Y
My controllers is something like this
#1: Panel 1 (DDP)
#2: Panel 2 & 3 (DDP)
#3: Virtual Matrix (DDP)
#4: K40 #1 (DDP)
#5: K40 #2 (DDP)
#6: F48 (e131 via FPP proxy)
#7+: Various WLED controllers (e131)
1, 2, & 3 are never touched.
I make quite a few changes on 4 through "n". If I touch 4 and add/remove a
single channel then I need to reprovision #5 too since it's DDP.
This spring I took a step back and tried to think about why I was using DDP
anywhere because in reality the only time there is any traffic on the
network is when I'm doing testing. The actual show is 100% multisync. I
don't care if there is the extra overhead for running e1.31 over DDP during
this testing so I figured I would punt.
Thanks for your feedback and I'll defer to you guys if this is deemed a
bug, feature, or even worth looking into.
…On Tue, May 18, 2021 at 12:29 PM Daniel Kulp ***@***.***> wrote:
I'm not saying this is not a bug, but the STRONG STRONG recommendation is
to use DDP to send data from xLights to FPP. I would recommend switching
the configuration from e1.31 to DDP. The recommended configuration works so
this bug would definitely be considered very low priority.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2648 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4XLQB7UUJUQUQU3PB7MX3TOKPWBANCNFSM45BIG2ZQ>
.
|
|
The intent of xLights only is that data is sent over the network by xLights when it is playing but when a show player is playing sequence (xSchedule or FPP) the data should not be sent ... typically because the data is being picked up from a local FSEQ file on a show player playing as a remote. This allows you to test from xLights pushing data and play from your show player without having to keep reconfiguring things. |
|
It should be noted that FPP ALWAYS uses absolute channel numbers so even when using e1.31, you would need to reconfigure channel numbers for outputs prior to being able to use any fseq file anyway. |
|
I wasnt commenting on the channel numbering ... just the intent of the setting. When uploading to the FPP master/player any outputs DDP or E131 or Artnet should be disabled if they are xLights only as the show player should not send them out. If it is better/easier not to upload them at all then that is also ok. |
|
Thanks Dan for clarifying that I still need to track absolute channels.
Based on that my personal use case for this is no longer valid.
I'll leave it to the core developers to determine if this (the e131 input
enable/disable based on xLights only) is a bug or not.
…On Tue, May 18, 2021 at 1:34 PM Keith Westley ***@***.***> wrote:
I wasnt commenting on the channel numbering ... just the intent of the
setting. When uploading to the FPP master/player any outputs DDP or E131 or
Artnet should be disabled if they are xLights only as the show player
should not send them out. If it is better/easier not to upload them at all
then that is also ok.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2648 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4XLQGMV2HFFLOGV5PMDT3TOKXMBANCNFSM45BIG2ZQ>
.
|
|
fixed with f49a54e |
Describe the bug
In the controllers tab of xLights if you have a FPP based controller with auto layout enabled and set it to "xLights Only" then when you click on upload input for the controller it does provision the e131 channels but it does not enable the checkbox therefor when doing testing from xLights with the FPP device in bridge mode. Switching to e131 & Active and pushing inputs does work as expected. DDP is not relevant to FPP inputs.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
My thoughts is that even though it's set to xLights only I should still be able to do testing from xLights sequencer without modifying the FPP configuration.
Screenshots
Versions (please complete the following information):
The text was updated successfully, but these errors were encountered: