Sean Meighan
Software => Xlights Setup => Topic started by: scuba on December 07, 2016, 05:52:38 AM
-
I need to add a 5 second front end to my sequence to help the FPP sync up with the controllers....I've tried several "fixes" but the best advice I've gotten is to add 5 seconds of silence to the front of each sequences to help the Pi load and play the next sequence.
What's the easiest way to add 5 seconds of silence to each sequence? I've made a 5 second sequence with audio.
BTW: I've tried several fixes, faster flash drive, turnoff this or that, nothing has helped solve the problem. A fellow FPP user tried the 5 second silent front end to each sequence and it worked!
-
Bump so I can find this at a later date. I want to do this exact thing--I want to use my sequence info from the original MS studio version of "God rest ye merry gentlemen" on the 1997 live version (next year!)....
-
I find it hard to believe the problem always induces an exact 5 second delay between the audio and the light data. Would be shame to do all that work to modify sequences and then the delay changes. If you want to fix it just alter the audio to be longer and then drag select all the effect and move them over. I had to do the same thing last night because I had audio that had extra stuff in front of a sequence someone shared so I selected and moved all the effects. It took 3 steps because the rows didn't fit on one screen.
-
Thanks Gil.
-
thanks guys...I've got 35 sequences...better get started..
Is there a way to select all of the model sequence data in one lift? 3 steps seems to be a bit much..did you need the resolution to be fine enough to align the effects with the true start go the audio?
-
Would probably be easier for us to add a time shift feature. Would only take like 15 minutes to create a routine that iterates through all effects and adds a time offset. We wouldn't be shifting audio though.
-
That would be great...There are several folks who could benefit from that..Sorry, I'm not a programmer..unless it's fortran
-
BTW: in comparison, the time it takes to do a 5 second shift in Audio is very small.... I takes about a minute to make the change..
-
Before doing all that work, you should try what I did. I just created a 5 second sequence (no audio) and placed it in front of the sequences that were not working correctly. My issue was with a lor controller that controls my 2 singing elements. Something happened after Halloween that doesn't allow the lor and fpp to work properly. Any new sequence I create (or old) does not work unless I place that 5 second sequence in front. It could be less than 5 seconds, I did not try. Once I got it working, I quit playing with it. I used 2.5 seconds on and 2.5 seconds off as suggested in another thread. My falcon controllers are working fine and all my sequences I uploaded before Halloween work fine. I improved some older sequences but I don't want to update the .fseq so I don't have to place more dead air in my show.
-
I tried the suggestion....not working...The FPP will not load the data sufficiently quick enough to make a smooth transition to execution....we see no issue with the Laptop running the schedule with the sequences...
Gil's suggestion that a 5 second 'in sequence' delay would allow the FPP to "catch up" seems to be valid, a few others have made the change..Because of the large amount of sequences, I'm looking to write a notebook++/Python script to add 5000ms to Starttime and Endgame throughout the XML files..
Slow going! mostly because a stink at scripting in Python!
-
The whole idea doesn't make sense. If you add 5 seconds to the sequence there is 5 more seconds of data so there is no "catching up" that FPP can do.
-
The real issue is why the delay in the first place.
Let me describe what the FPP playing of the Sequence does: The audio comes on, the lights don't blink; then the lights appear to rapidly flash, in sequence with what was programed-- catching up with the audio; then all is sync'd between the audio and the lights and the rest of the sequence plays without any issue. Next sequence: same behavior.
Up on FalconChristmas, one guy had the same problem and put a 5 second "silence no lights" on front end on his sequence and the problem went away. BTW: When running the show on the Laptop, no problems. The 5 seconds "allows" the FPP to catchup without any lights blinking and sync up for the rest of the sequence. no one see's the funny behavior.
"The whole idea doesn't make sense"
-
Ok I get what you mean now. I couldn't figure out how the FPP could "catch up". So what I'm hearing is after a few seconds the data is all in sync. So I would suspect some kind of network issue. Are you sure there is no unicast controller the FPP is having trouble communicating with? That's the kind of thing that can cause lag.
-
All the communication is Multicast thru a 3com 100 mbps switch full duplex..should be fast enough. The controllers are all E68X's (latest firmware)..never had an issue before. And with the xlights scheduler there is no issue.
-
What model Pi is it?
-
B+
-
So that's the older one before Pi2 I believe. I think that's the same model I use. It's been so rock solid I never upgraded to the Pi2 or Pi3 even though I own both of them.
-
I bought in November 2014
700MHz Broadcom BCM2835 CPU / 512 MB SDRAM @ 400MHz / 10/100 Ethernet RJ45 on-board network
Full size HDMI / 4 USB ports / Micro SD slot
GPIO header expanded (40 pins vs. 26)
New 4-pole connector replaces the existing analogue and composite video port on the Model B
-
I also have a Pi2:
Raspberry Pi 2 (RPi2) Quad-Core 900 MHz 1GB RAM
-
Preliminary results: I change to the Pi 2..loaded the same flash drive. It seems that the "catching up" issue is much improved...I need to spend some time to night looking at the show to see if there is improvement across the 35 sequences.
I'll keep you posted...
-
Not sure if you're troubleshooting this on the Falcon forum but I'd say that is the best spot to get the Capt to help figure it out.
-
I would agree but not a word from him on this issue.. I've basically mirrored this issue on that forum..
I'm about to look at the whole sequence of sequences to evaluate if the issue is resolved..I'll let you know
-
I would agree but not a word from him on this issue.. I've basically mirrored this issue on that forum..
He has been very busy and with the increased forum activity from lots of users' last-minute setup questions, as of earlier tonight he was 10 whole pages of forum threads behind. After a few hours of time this evening on the couch with a laptop, he is now only 6 pages behind but he did post some suggestions in your thread on one of those 4 pages he has now cleared. I'm sure the 6 pages he has left will quickly become 7 tomorrow and he'll be falling behind again.
Signed "He" :)
-
Sorry if I sounded critical, not my intention...I've been watching the Falconchristmas activity and it's been nuts.
Just checked FalconChristmas forum: Yesterday I moved over the show to the Pi 2 Quad core....after testing last night (after hours) there appears to be very little delay: 100 - 150 ms. Unless you know what to look for, it's invisible!
Thanks to all!
Here's CaptianMurdoch's response to the delay issue:
I have a ToDo item to rework the MultiSync code to add a "open" step. Currently the master just tells the remotes to start playing and they do their best to start in sync. I want to add an "open" before the "start", so that everyone gets a chance to open the files first then the start message comes.
It sounds like your video files are taking a while to start up. Sometimes different encodings can make the files take longer to start. If your video files have long distances between keyframes and the encoding method requires both keyframes to properly decode the video frame in the middle then it can delay startup since omxplayer has to read in a larger amount of data and decode more frames before actually starting to play the video. You might try re-encoding one of your video files with a shorter distance between keyframes and also turn off 'B' frames if they are turned on.
Other possible solutions include making sure that the USB drives on the Remote are as fast as possible, using a quad-core Pi rather than a single-core Pi, making sure that there are no other channel outputs on the Pi that is running video, and removing any fseq files from the Pi running video. If your have the fseq files on the video player Pi, then it will also be reading in the fseq data which can cause USB bus contention and slow down video startup.[/b
-
I just pushed an enhancement for next release. Under the Edit menu there will be a "Shift Effects" option. You can type in 5000 to push everything 5 seconds to the right. You could type in -1500 to shift everything 1.5 seconds to the left. It will truncate effects that are shifted left past zero or delete them entirely if the end point moves past zero.
-
Just got back in town ...thanks Gil