Author Topic: Removing the last Ver 1.X update.  (Read 1625 times)

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: Removing the last Ver 1.X update.
« Reply #45 on: January 13, 2019, 09:20:51 PM »
So discovery is still broadcast based with the new mechanism?  I thought I heard mention of it moving to multicast.  That could help make it work across routers.

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: Removing the last Ver 1.X update.
« Reply #46 on: January 13, 2019, 10:03:04 PM »
So discovery is still broadcast based with the new mechanism?  I thought I heard mention of it moving to multicast.  That could help make it work across routers.

Dan did add support to use multicast for the All Remotes option, but discovery is still a broadcast packet.

We could probably add support for multicast discovery if it makes sense, but would probably keep the broadcast as well for compatibility for now.
-
Chris

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,583
  • Kudos: 92
    • KulpLights.com
Re: Removing the last Ver 1.X update.
« Reply #47 on: January 14, 2019, 05:46:57 AM »
Thanks, that will help. I am interested in the discovery mechanism as well. The Avahi stuff was a bit of a pain on the windows platform. I am hoping the new variant is more friendly. I also run multiple FPP instances on on different vlans, so discovery never worked for me. I am not sure if the new discovery means will do much to help that or not.


One thing that FPP now does is every instance always records all of the "Pings" it receives.  Thus, every instance knows about every other instance on the the local vlan.   Thus, if you can find one, you can query it for the list of everything it knows and get the full list.   That's how the new FPP Connect works.   If it cannot find it based on the broadcast packet, you can tell it one and it then queries it for everything it knows and gets the full list.   


What you can ALSO do it add a wifi adapter to one and have it be on both networks.   It would discover it on the local network, then query it for everything it knows and discover all the others on the "other" network.   

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: Removing the last Ver 1.X update.
« Reply #48 on: January 14, 2019, 07:59:37 AM »
To add to Dan's comment, about not having to discover to get the list of systems.  You can hit a REST endpoint on any fppd system and get the list of systems that FPP system knows about.  On any FPP v2.x system, hit http://fppIP:32322/fppd/multiSyncSystems and on FPP v2.6 and up, you can also now hit http://fppIP/api/fppd/multiSyncSystems

The first URL goes directly to the webserver built into fppd listening on port 32322.  This webserver is only for the fppd internal REST API.  An update in FPP v2.6 allowed the second URL above which goes through the Apache web server and gets proxied back to fppd.  The discover and reply packets only contain info about the system sending the packet, but fppd will respond to this API call with a list of all known systems.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,420
  • Kudos: 45
Re: Removing the last Ver 1.X update.
« Reply #49 on: January 14, 2019, 08:33:45 AM »
To add to Dan's comment, about not having to discover to get the list of systems.  You can hit a REST endpoint on any fppd system and get the list of systems that FPP system knows about.  On any FPP v2.x system, hit http://fppIP:32322/fppd/multiSyncSystems and on FPP v2.6 and up, you can also now hit http://fppIP/api/fppd/multiSyncSystems

I get this on both V2.6 and V2.x-140 

{"message":"endpoint does not exist","respCode":404,"status":"ERROR"}
-Mark

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: Removing the last Ver 1.X update.
« Reply #50 on: January 14, 2019, 09:34:10 AM »
To add to Dan's comment, about not having to discover to get the list of systems.  You can hit a REST endpoint on any fppd system and get the list of systems that FPP system knows about.  On any FPP v2.x system, hit http://fppIP:32322/fppd/multiSyncSystems and on FPP v2.6 and up, you can also now hit http://fppIP/api/fppd/multiSyncSystems

I get this on both V2.6 and V2.x-140 

{"message":"endpoint does not exist","respCode":404,"status":"ERROR"}

Make sure you have the case correct.   'multiSyncSystems'

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,583
  • Kudos: 92
    • KulpLights.com
Re: Removing the last Ver 1.X update.
« Reply #51 on: January 14, 2019, 10:08:39 AM »
One note about that REST API:  that returns the list of systems that that FPPD has ever seen since it was started.   That may include systems that are no longer available.   Not a huge deal, but something to be aware of.


Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: Removing the last Ver 1.X update.
« Reply #52 on: January 14, 2019, 10:34:13 AM »
You can check the 'lastSeen' and 'lastSeenStr' fields to see when fppd last saw a discovery/ping packet from another server.  Maybe we should add 'rediscover' endpoint to the API to clear the list and trigger a discovery, or a periodic discovery to allow us to easily clean up old systems.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,420
  • Kudos: 45
Re: Removing the last Ver 1.X update.
« Reply #53 on: January 14, 2019, 11:08:55 AM »
Make sure you have the case correct.   'multiSyncSystems'

I did have the case wrong, but now, trying again with the correct case I get this...

{"message":"endpoint fppd/mulitSyncSystems does not exist","respCode":404,"status":"ERROR"}

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Removing the last Ver 1.X update.
« Reply #54 on: January 14, 2019, 11:13:09 AM »
multiSyncSystems not mulit. :) and thats why I just made a quick add to see what the endpoint being hit was, so I could easily see typos.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,420
  • Kudos: 45
Re: Removing the last Ver 1.X update.
« Reply #55 on: January 14, 2019, 11:21:46 AM »
multiSyncSystems not mulit. :) and thats why I just made a quick add to see what the endpoint being hit was, so I could easily see typos.


LOL man you got me.   ;D  I swear I read that over and over to make sure I had the *case* right and completely missed the letter swap  :-[

Offline jeffu231

  • Newbie
  • *
  • Join Date: Sep 2014
  • Location:
  • Posts: 9
  • Kudos: 0
Re: Removing the last Ver 1.X update.
« Reply #56 on: January 14, 2019, 04:10:31 PM »
In my setup , I have 3 vlans to segregate the 3 distinct portions of my show. I.E 3 houses on the same street. Each location has a dedicated show network on it's own vlan and those are routed between each other. They never see the broadcast packets between each other. So I have to go in and put the ip addresses of the 2 remotes in the master so it directly sends sync packets to them. It worked fine, but they don't know anything about each other. I would think there might be others with a similar setup. I have been practicing sparse population of the FPP files by managing them as separate export configurations in Vixen. I export just the required data to each individual FPP instance and thus all they need to do is just get the sync packets to stay in sync. 

Offline tbone321

  • Hero Member
  • *****
  • Join Date: Oct 2014
  • Location:
  • Posts: 1,587
  • Kudos: 50
Re: Removing the last Ver 1.X update.
« Reply #57 on: January 14, 2019, 04:49:43 PM »
In my setup , I have 3 vlans to segregate the 3 distinct portions of my show. I.E 3 houses on the same street. Each location has a dedicated show network on it's own vlan and those are routed between each other. They never see the broadcast packets between each other. So I have to go in and put the ip addresses of the 2 remotes in the master so it directly sends sync packets to them. It worked fine, but they don't know anything about each other. I would think there might be others with a similar setup. I have been practicing sparse population of the FPP files by managing them as separate export configurations in Vixen. I export just the required data to each individual FPP instance and thus all they need to do is just get the sync packets to stay in sync.


What is the point of the 3 vlans?  Unless you are using a lot of multicast, a good switch would provide the same isolation for show data and still allow the broadcast packets and other features to work properly jf the 3 houses are cabled together.

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: Removing the last Ver 1.X update.
« Reply #58 on: January 14, 2019, 05:14:38 PM »
Im not up to speed totally on multicast but I dont think that will make it through a normal router unless you have multicast routing turned on.   I am in a similar situation with my show network in one VLAN and dev in another separated by an OpenWrt router.  I will think about adding multicast discovery.

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: Removing the last Ver 1.X update.
« Reply #59 on: January 14, 2019, 05:37:26 PM »
Im not up to speed totally on multicast but I dont think that will make it through a normal router unless you have multicast routing turned on.   I am in a similar situation with my show network in one VLAN and dev in another separated by an OpenWrt router.  I will think about adding multicast discovery.
You're right, it wouldn't make it thru a normal "home" router.  But vlans won't work on most of those either.  So if you're at that point, you probably have routers that can be set up to route the multicast.  I know just enough to be dangerous in this area.  In order for it to work, IGMP needs to be working.  all of the devices would need to join the multicast group on a specific multicast address.  The mrouter should manage the IGMP memberships and should route the the multicast traffic appropriately.  That's just the theory though, I haven't personally played with this kind of configuration.

If I recall Jeff's setup, the multiple houses aren't adjacent, they have long haul wifi links between the routers.  That's another reason why multicast would be preferred over broadcast.

 

Back to top