Author Topic: Hmmm...this is new...  (Read 682 times)

Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #15 on: November 06, 2018, 04:34:03 PM »
I can't remember, but do you have an ethernet cable going to the BBB?  If so you could just go to the non BBB end and plug it into a laptop. set the laptop ip to the .5 network and connect up.


Yes, I do, and that's probably what I'll end up doing to set this up.  ;)

Offline Babybear

  • Full Member
  • ***
  • Join Date: Jan 2016
  • Location: Rochester, New York
  • Posts: 164
  • Kudos: 2
Re: Hmmm...this is new...
« Reply #16 on: November 06, 2018, 06:39:01 PM »
Something is catching me here If I recall last year I thought I was told your remotes can not be on subnets maybe Dan can Jump in and clear that up.
But to get to your BBB you can write a route statement that will let you get past the Pi into the BBB


C:/>route -p add 192.168.5.xx mask 255.255.255.0 192 168.1.xx
                               BBB                                              Pi
this is in windows Command prompt
JimmyG
Rochester, New York

Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #17 on: November 06, 2018, 07:23:31 PM »
Something is catching me here If I recall last year I thought I was told your remotes can not be on subnets maybe Dan can Jump in and clear that up.
But to get to your BBB you can write a route statement that will let you get past the Pi into the BBB


C:/>route -p add 192.168.5.xx mask 255.255.255.0 192 168.1.xx
                               BBB                                              Pi
this is in windows Command prompt

First, thanks for that command - I will try that before having to drop my matrix as it is hung with chains over my garage and needs extra people to raise/lower it. This would save lots of headache.

Second, it's not on a subnet - my show is on its own network that is not part of my home network. I have 3 E682 controllers, 2 Remote BBBs (1 for the video/display matrix and 1 for the Tune To matrix), with a Rasp Pi controlling everything. All ethernet plugs from all the controllers run to an 8 port unmanaged switch. I decided on the 192.168.5.xxx network so as to not confuse any controller or myself. The Pi has 2 addresses: ETH0 is 192.168.5.100 & WLAN is 192.168.1.150 so I can "remote in" with a tablet or PC. I suppose it's still part of my home network, but none of the controllers can cross over and use up bandwidth on my home network -- at least, that's how I understand it after seeing posts about setting up a show network (and watching a couple xLights videos about the same thing).

This whole thing is just odd...the P10 display matrix shows no errors or issues and lets me perform a Multisync, and only *after* any video is shown does it stop responding.


Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #18 on: November 06, 2018, 08:09:00 PM »
Something is catching me here If I recall last year I thought I was told your remotes can not be on subnets maybe Dan can Jump in and clear that up.
But to get to your BBB you can write a route statement that will let you get past the Pi into the BBB


C:/>route -p add 192.168.5.xx mask 255.255.255.0 192 168.1.xx
                               BBB                                              Pi
this is in windows Command prompt
The route command was accepted (I got Ok! after typing it), but I still can't access the BBB. I tried connecting directly to the BBB at 192.168.5.150 from a web browser, and I also went into Multisync and clicked the P10/BBB (underlined in blue) device - neither worked. I freely admit I'm not a networking person, so if I am doing this wrong... :o
« Last Edit: November 06, 2018, 08:16:33 PM by Stormyblade »

Offline Babybear

  • Full Member
  • ***
  • Join Date: Jan 2016
  • Location: Rochester, New York
  • Posts: 164
  • Kudos: 2
Re: Hmmm...this is new...
« Reply #19 on: November 06, 2018, 08:14:09 PM »
On the Pi in the FPP in the networking you have checked routing through pi at the lower left corner of the page

Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #20 on: November 06, 2018, 08:16:02 PM »
Yes, that's been checked since I set up the Pi.

Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #21 on: November 08, 2018, 08:12:43 PM »
Dan asked for a log file a few days ago...I started work and couldn't get to my system for a couple days but now I have the zip file included in this reply.  Hoping Dan (or someone else) can take a look at this and let me know what is going on??

Online dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: Hmmm...this is new...
« Reply #22 on: November 09, 2018, 05:47:13 AM »



You have a LOT of e1.31 OUTPUT universes defined pointing at itself.   Thus, I think you are flooding itself with universes that no-one is reading (it's not in bridge mode so we don't setup a listener).   My gut feeling is the buffers in entire network stack are full so the various packets are being dropped.  Anyway, if you aren't outputting e1.31 remove all of those universes.   Certainly don't send them back to yourself.


I'll try and add a check to make sure none of the UDP outputs will send data to itself.  That's just asking for trouble.   However, the fix for you is "don't do that".  :)



Dan Kulp

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: Hmmm...this is new...
« Reply #23 on: November 09, 2018, 07:43:11 AM »
I'll try and add a check to make sure none of the UDP outputs will send data to itself.  That's just asking for trouble.   However, the fix for you is "don't do that".  :)


I see its already been committed in master-branch.  Nice!    But I also saw this snuck in with it  ;D  ...

Quote from: github
Don't configure UDP outputs that point at myself.  Allow fseq.gz file upload
ooooooh christmas may be coming early!  8) Probably belongs in a new thread, but it still falls under the heading of "Hmmmm...this is new...  ;D ;D ;D
« Last Edit: November 09, 2018, 07:51:15 AM by pixelpuppy »
xLights and Vixen3 for sequencing / FPP for scheduling and playing / Falcon controllers for pixels / homemade controllers for everything else

Online dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: Hmmm...this is new...
« Reply #24 on: November 09, 2018, 11:59:17 AM »
Quote from: github
Don't configure UDP outputs that point at myself.  Allow fseq.gz file upload
ooooooh christmas may be coming early!  8) Probably belongs in a new thread, but it still falls under the heading of "Hmmmm...this is new...  ;D ;D ;D


I'm testing some updates to the FPP Connect stuff in xLights that will compress the fseq files before sending them.   It also will use the HTTP upload (same as drag/drop onto the Files page) instead of FTP.   rsync is still faster if the files already exist (rsync just sends deltas), but it definitely helps.    Hopefully next build of xLights.








Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #25 on: November 10, 2018, 02:56:57 AM »



You have a LOT of e1.31 OUTPUT universes defined pointing at itself.   Thus, I think you are flooding itself with universes that no-one is reading (it's not in bridge mode so we don't setup a listener).   My gut feeling is the buffers in entire network stack are full so the various packets are being dropped.  Anyway, if you aren't outputting e1.31 remove all of those universes.   Certainly don't send them back to yourself.


I'll try and add a check to make sure none of the UDP outputs will send data to itself.  That's just asking for trouble.   However, the fix for you is "don't do that".  :)


Dan,


First off, a thousand thanks for looking at this. I know it's crunch time for a lot of folks around here.


Second, when you say I have "a LOT of E1.31 universes defined pointing at itself" do you mean my matrix? I set it up that way per videos I've seen on the xLights website.  Are you saying that on the BBB FPP setup page I don't need *any* inputs or outputs set up for E1.31, but just set up the LED Panels tab with my configuration, on the Inputs tab (assuming I am running v2.3)?


Forgive my questions if they sound silly, but I'm still trying to get this set up correctly -- if I knew more about this DDP stuff, I'd run it that way, but I am reluctant to change things around for fear of losing models/props...unless switching to DDP in xLights and within FPP would help?

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: Hmmm...this is new...
« Reply #26 on: November 10, 2018, 05:47:35 AM »
On a BBB P10 panel, you should have no entries on the E1.31/Artnet channel outputs page and no check in the Enable box. If you do, it is sending out E1.31 data to somewhere and Dan thinks it is "to itself " (same IP as itself)

On a P10, the output is LED Panels, not E1.31.

Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #27 on: November 10, 2018, 09:09:05 AM »
On a BBB P10 panel, you should have no entries on the E1.31/Artnet channel outputs page and no check in the Enable box. If you do, it is sending out E1.31 data to somewhere and Dan thinks it is "to itself " (same IP as itself)

On a P10, the output is LED Panels, not E1.31.

I know I have nothing on the E1.31 outputs page, but  I will go back and check settings again - as far as I know, the only tab with entries is the LED/Panels one.

Offline Stormyblade

  • Jr. Member
  • **
  • Join Date: Oct 2017
  • Location: Cornelius, Oregon
  • Posts: 87
  • Kudos: 1
Re: Hmmm...this is new...
« Reply #28 on: November 12, 2018, 01:08:44 AM »
Well, I was finally able to check the settings on my BBB earlier today and it turns out I had 60 universes of E1.31 set up on the E1.31/Artnet outputs tab. The Enable Outputs box was not checked, but all 60 universes had the Active box checked. I do not remember adding those 60 universes, but nevertheless they were there, set to Unicast, and with the IP address of my BBB. After de-checking the Active box for all 60 universes (I didn't want to delete them just in case I wasn't supposed to), I tried playing a couple sequences that had video. SUCCESS!! Not only did video play any time I started a sequence or playlist, but the video played even smoother than before. I ran through a playlist 3 times, and independently chose sequences that did not have video then ones that did just to see if I could duplicate my original issue...and I couldn't. Which makes me really happy.  :D

HUGE thanks to Dan for catching this, and another big thanks to JonB256 for offering great advice and suggestions, and most importantly, clarifying info on my lack of understanding.

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: Hmmm...this is new...
« Reply #29 on: November 12, 2018, 04:28:15 AM »
It sounds like, even though the Enable box was not showing as checked, it was acting like it was.
That is a something that to look out for but I'm not quite sure how I would do that. Perhaps Dan can explain which Log file gave him the clue.

It could explain a lot of "jerky" video scenarios that don't seem to have an explanation.

 

Back to top