Sean Meighan
Welcome => Do You Need Help? Post it here => Topic started by: meeks on November 04, 2015, 07:28:08 PM
-
hey all, I know i read somewhere about doing a playback in xlights while the pi is running and f16s on that the lights were way behind the playback and choppy at best. Im using the latest xlights all the latest firmware on all falcon hardware but looks really bad.
-
There is an issue that recently came up on the Falcon forum that if you are using an Etherdongle there is an issue that was just found and a fix (cross your fingers) coming in the next few days. If you don't use an etherdongle just ignore this post.
-
All falcon hardware.
Pi-fpd-f16v1
-
After I posted this last night, I couldn't sleep with the frustration so I went back to check all me settings and tried it again and now xlight preview screen doesn't have and lights working in the preview screen and no data is going to the pi either. Now I'm scratching my head with both hands. Any help would be greatly appreciated.
-
Sometimes I hit play and it looks like nothing is working in the model preview window then I realize I haven't clicked on any models in the row headings to tell the window what to preview.
-
I did a couple of transitions and nothing was playing. The model nor the whole house.
-
Some people are reporting you gotta hit Render after opening the sequence for it to preview. That shouldn't be a requirement but I haven't had time to investigate.
-
I have a couple of sequences that are like that. Even thought fseq is there, no render = no preview on the sequencer tab.
I'll try to figure out which ones they are and send you the XML.
-Steve
-
I'll do the same when I get off of work. Thanks guys..
-
I rendered the sequences and they are working fine now. The choppy playback is still there working overtime.
-
So , you are using the Output lights to connect to theF16v1 and lights directly ? Are you using Unicast and there should have been another controller ?
If not , can you try uploading the fseq to the Pi and playing it there ?
-
So , you are using the Output lights to connect to theF16v1 and lights directly ? Are you using Unicast and there should have been another controller ?
I am using unicast
If not , can you try uploading the fseq to the Pi and playing it there ?
I am using unicast.
I am using xlights>pi>fpd>f16v1
Rendering did fix one issue with letting me see the playback thru the visualizer. Last night, I did try 1 last time before going to bed, I tried a single controller with the mega tree 2400 channels and it played horrible so I turned another controller on and it played perfect with lights without any hesitation. So I went back into xlights to the layout tab and found that my custom model shows 800 nodes but when I checked the node layout it said 796 nodes and showed 4 spots with nothing filled in the square. So maybe this particular controller is acting up because of this or something I did there. I'm also gonna pic the controller again and see if this helps too. I will check this evening when I get home. I'll post my findings.
-
If you are using unicast you must power up all the controllers you have defined and set as Enabled in the setup tab otherwise playback can be choppy. I haven't looked back at the whole thread but I assumed that had to be one of the first things someone would have mentioned. We only talk about it 3 times a week. I see in your troubleshooting you say "I turned another controller on"....so sounds like that's your problem.
-
If you are using unicast you must power up all the controllers you have defined and set as Enabled in the setup tab otherwise playback can be choppy. I haven't looked back at the whole thread but I assumed that had to be one of the first things someone would have mentioned. We only talk about it 3 times a week. I see in your troubleshooting you say "I turned another controller on"....so sounds like that's your problem.
I thought the same, but I started testing the other day and out of 8 controllers only had one connected and saw no lag or choppy playback. Everything is setup as unicast. I'm playing using xlights. I think it's a different story with fpp.
-
If you are using unicast you must power up all the controllers you have defined and set as Enabled in the setup tab otherwise playback can be choppy. I haven't looked back at the whole thread but I assumed that had to be one of the first things someone would have mentioned. We only talk about it 3 times a week. I see in your troubleshooting you say "I turned another controller on"....so sounds like that's your problem.
I thought the same, but I started testing the other day and out of 8 controllers only had one connected and saw no lag or choppy playback. Everything is setup as unicast. I'm playing using xlights. I think it's a different story with fpp.
Why would there be an issue with not having all the controllers on? Just curious. I've tested only 1 before and didn't have an issue with all the others enabled but not on. Again, I'm just curious.
How would the fpp cause something like this?
-
I just going by what the networks geeks around here and the FPP site keep saying. Something about continual ARP requests trying to find the controller for all the packets we are trying to blast to that IP address. All because one person is getting away with it doesn't mean it's a good idea. You're having trouble so can it hurt to try disabling the ones that aren't powered up? It's just clicking a few flags in the setup page then click them back on when you're done. I assume you have the Pi in bridge mode cause that's the only way to play to it from xLights. When I troubleshoot I disable all outputs I'm not testing on both the Pi and xLights.
-
Hi , its not just FP . If using Uncast, then this issue can / will arise even if laying via a laptop. Basically in multicast, its a broadcast fire and forget paradigm. In Unicast , the ARP requests expect a response and hence the 'pause'.
Its the first thing I ask , cause I spent much time on this last year troubleshooting when I had mine setup as Uncast (I was set that way for me)
-
I have noticed this issue with unicast using both laptop and fpp. I also noticed that I can get away with some controllers not turned on and things will run ok but other controllers have to be on. Definitely the problem goes away once those controllers are turned on but just to bare in mind that it appears to be ( in my setup anyway) that it can vary depending on which controllers are on and which are off. I'm going multicast this year.
Sent from my iPhone using Tapatalk
-
Hi , its not just FP . If using Uncast, then this issue can / will arise even if laying via a laptop. Basically in multicast, its a broadcast fire and forget paradigm. In Unicast , the ARP requests expect a response and hence the 'pause'.
Its the first thing I ask , cause I spent much time on this last year troubleshooting when I had mine setup as Uncast (I was set that way for me)
I haven't seen this issue yet, but shouldn't it just happen on the first time a sequence is played? Once the switch learns which IP addresses are on which port, the arp stops? What happens if you just ping each controller once and then play?
-
I don't know Steve. My routers are just plain normal ones (ie nothing sophisticated) , so after I figured out the problem , I simply ensured that the other controllers were on after that. This year am using multicast, unless I see an issue.
-
While unicast has its benefits, multicast is just fine and can be greatly enhanced by using a managed switch with igmp snooping.
-
UPDATE.. After running all controllers like what was suggested, and rendering the sequence, everything is running like a kangaroo on speed. So I think running all controllers was the issue for me.
Thanks guys for all your help and tolerance.