Send packets out to Pi earlier then show starts?

[brichi]

Hi guys, I was wondering now that I got my sequence finished and up and running in xlights if theres a way for scheduler to talk to the falcon software on the Pi a few seconds before the showtime starts

Reason im asking is I have a video right in the beginning of my sequence with words and someone talking, I set the schedule as a test to start at 5:00, it triggers at 5 and the lights start but the Pi tends to start about 4-5 seconds after so now the audio and mouths are way off for about 10-15 seconds while the show tries to catch up

I have the xscheduler in master and my Pi in remote mode and the FSEQ file loaded on the pi along with all the videos it needs

thanks for any changes that may be able to be made!

[CaptainMurdoch]

I need to document the new “open” sync command which I will be adding to FPP shortly which is meant to help with the initial sync in situations like this.  Essentially the master will tell the remotes to open and get ready and then they can start playing as soon as the first sync packet is received.  I haven’t yet looked at the xScheduler code to see when it sends the start packet but in FPP right now it is sent a little early to try to give the remote time to spin up before the first frame is played.  That timing is still a race between master and remote though as to who opens and starts playing a file first.  The new command should let systems start in sync better.  Currently if systems are running mismatched hardware the initial sync can be off by a second or so and take a couple seconds to pull in.  Another fix I will be looking at is making the remote seek to pull into sync quicker but skipping frames could be just as bad so that is not a fix for this issue, only a bandaid for really bad sync issues.

[brichi]

thx for the info, definitely looking forward to the updates

[keithsw1111]

I need to document the new “open” sync command which I will be adding to FPP shortly which is meant to help with the initial sync in situations like this.  Essentially the master will tell the remotes to open and get ready and then they can start playing as soon as the first sync packet is received.  I haven’t yet looked at the xScheduler code to see when it sends the start packet but in FPP right now it is sent a little early to try to give the remote time to spin up before the first frame is played.  That timing is still a race between master and remote though as to who opens and starts playing a file first.  The new command should let systems start in sync better.  Currently if systems are running mismatched hardware the initial sync can be off by a second or so and take a couple seconds to pull in.  Another fix I will be looking at is making the remote seek to pull into sync quicker but skipping frames could be just as bad so that is not a fix for this issue, only a bandaid for really bad sync issues.

We should talk Chris.


Sent from my iPhone using Tapatalk

[brichi]

I need to document the new “open” sync command which I will be adding to FPP shortly which is meant to help with the initial sync in situations like this.  Essentially the master will tell the remotes to open and get ready and then they can start playing as soon as the first sync packet is received.  I haven’t yet looked at the xScheduler code to see when it sends the start packet but in FPP right now it is sent a little early to try to give the remote time to spin up before the first frame is played.  That timing is still a race between master and remote though as to who opens and starts playing a file first.  The new command should let systems start in sync better.  Currently if systems are running mismatched hardware the initial sync can be off by a second or so and take a couple seconds to pull in.  Another fix I will be looking at is making the remote seek to pull into sync quicker but skipping frames could be just as bad so that is not a fix for this issue, only a bandaid for really bad sync issues.

Hey guys! I have my screen stored away so hard to test all this but wanted to see if there were improvements in this area, thanks as always!