Author Topic: FPP 2.3 now available  (Read 3602 times)

Offline ncosper

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 59
  • Kudos: 0
Re: FPP 2.3 now available
« Reply #30 on: October 29, 2018, 09:39:43 PM »
Thanks for all your work Dan. Multisync is definitely working better but I'm still seeing some odd issues with it. If a remote is playing an MP4 it will often play significantly faster than an accompanied fseq. It's a little Chipmunky if any voices are on the MP4 audio. I put any remotes playing mp4's on 2.2 with the master on 2.3 and they seem to work well.
Thanks again for working on this!


Sent from my iPhone using Tapatalk

Offline Babybear

  • Full Member
  • ***
  • Join Date: Jan 2016
  • Location: Rochester, New York
  • Posts: 164
  • Kudos: 2
Re: FPP 2.3 now available
« Reply #31 on: October 30, 2018, 03:54:05 AM »
what I have found it's all working good only when I used burned images of 2.3 and not upgrades. the video was off 1 second for the first 2 then spot on after that. ran 3 hours straight with no crashes.
JimmyG
Rochester, New York

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: FPP 2.3 now available
« Reply #32 on: October 30, 2018, 08:40:30 AM »
Thanks for all your work Dan. Multisync is definitely working better but I'm still seeing some odd issues with it. If a remote is playing an MP4 it will often play significantly faster than an accompanied fseq. It's a little Chipmunky


Yes, to Dan, a big THANK YOU for all your work on this.  I'm sure you're busy with your own show (and work, and home life, etc. etc.) so I really appreciate the time you've taken to look into this.   With 2.3 multisync is definitely better but there are still some oddities going on.  I've been testing, playing, and scouring the logs and see some interesting things:


- Start-Synced-Sequence packet and Sync-Fseq-To-Frame-x packet gets sent before Start-Synced-Media.   Since Media seems to have more startup delay than fseq data, perhaps sending StartSyncedMedia before StartSyncedSequence could help a bit with startup delay delta. 


- Start-Synced-Sequence packet is immediately followed by Sync-Fseq-To-Frame-0.  However, Start-Synced-Media packet is not immediately followed by Sync-Media-To-xxx-Seconds.  Perhaps following Start-Synced-Media with a Sync-Media-To-0.00-Second would help it work more like fseq-sync?  (i.e. send the 1st Media-Sync at 0.00 instead of 1/2 second after playback started.)


- Because of the recent enhancement to delay speed changes until two consecutive new deltas, I think that almost forces a minimum 1 second delay at startup. (two consecutive 0.5 second sync packets)


What happens in the first few seconds is interesting...
  • Three Fseq-sync packets (frames 0,3,7 or 1,4,8) are received (taking up about a half-second)
  • 1st Media-Sync is received with Master at 0.52 Local playback is at 0.00, Difference of -522ms.  Current delta 0, new delta of 10 frames is noted but no action taken until next sync to verify (recent enhancement).
  • 2nd Media-Sync with Master at 1.01 Local at 0.07 and a diff of -940ms and new delta 15, Speedup 15 steps (why not 19@50ms?  Is 15 the maximum?)
  • 3rd Media-Sync with Master at 1.52, Local at 0.62, diff of -900ms.  Current delta 15, new delta 15, no speed changes made
  • 4th Media-Sync with Master at 2.01, Local at 1.41, Diff -598ms, Current delta 15, new delta 11, Slowdown 3 steps
  • 5th Media-Sync with Master at 2.52, Local at 2.21, Diff -399ms, Current delta 11, new delta 7, Slowdown 4 steps
  • 6th Media-Sync with Master at 3.01, Local at 2.72, Diff -286ms, Current delta 7, new delta 5, Slowdown 2 steps
  • 7th Media-Sync with Master at 3.52, Local at 3.31, Diff -207ms, Current delta 5, new delta 4, Slowdown 1 step
  • 8th Media-Sync with Master at 4.01, Local at 3.85, Diff -155ms, Current delta 4, new delta 3, Slowdown 1 step
  • 9th Media-Sync with Master at 4.52, Local at 4.09, Diff -426ms, Current delta 3, new delta 8, Speedup 5 steps
  • 10th Media-Sync with Master at 5.00, Local at 4.67, Diff -333ms, Current delta 8, new delta 6, Slowdown 2 steps
  • 11th Media-Sync with Master at 5.51, Local at 5.26, Diff -254ms, Current delta 6, new delta 5, Slowdown 1 step
So it starts off about 1 second behind and after a few seconds of playback it gets to less than a half-second difference.  But after that it keeps swinging back and forth, faster-slower-faster-slower in the 100-400ms range, but never zeroes in.


Code: [Select]

2018-10-30 07:27:35 (1228) MultiSync.cpp:1213:StartSyncedSequence(Trees Talking 2.fseq)
2018-10-30 07:27:35 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 0
2018-10-30 07:27:35 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 0   filetype: 1   frameNumber: 0
2018-10-30 07:27:35 (1228) MultiSync.cpp:1252:StartSyncedMedia(Trees Talking 2.mp3)
2018-10-30 07:27:35 (1228) mediaoutput/mediaoutput.c:127:OpenMediaOutput(Trees Talking 2.mp3)
2018-10-30 07:27:35 (1228) mediaoutput/mediaoutput.c:175:Master is playing Trees Talking 2.mp3 audio, remote will try Trees Talking 2.mp4 Video
2018-10-30 07:27:35 (1228) mediaoutput/MediaOutputBase.cpp:41:MediaOutputBase::MediaOutputBase()
2018-10-30 07:27:35 (1228) mediaoutput/omxplayer.cpp:54:omxplayerOutput::omxplayerOutput()
2018-10-30 07:27:35 (1228) mediaoutput/omxplayer.cpp:79:omxplayerOutput::Start()
2018-10-30 07:27:35 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 3
2018-10-30 07:27:35 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 7
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:36 (1228) mediaoutput/mediaoutput.c:296:Master: 0.52, Local: 0.00, Diff: -522ms, delta: 0, new: 10
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 11
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 15
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 19
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:36 (1228) mediaoutput/mediaoutput.c:296:Master: 1.01, Local: 0.07, Diff: -940ms, delta: 0, new: 15
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 23
2018-10-30 07:27:36 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 27
2018-10-30 07:27:37 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:37 (1228) mediaoutput/mediaoutput.c:296:Master: 1.52, Local: 0.62, Diff: -900ms, delta: 15, new: 15
2018-10-30 07:27:37 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 31
2018-10-30 07:27:37 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:37 (1228) mediaoutput/mediaoutput.c:296:Master: 2.01, Local: 1.41, Diff: -598ms, delta: 15, new: 11
2018-10-30 07:27:37 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:37 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:37 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:37 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:37 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 47
2018-10-30 07:27:38 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:38 (1228) mediaoutput/mediaoutput.c:296:Master: 2.52, Local: 2.12, Diff: -399ms, delta: 11, new: 7
2018-10-30 07:27:38 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:38 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:38 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:38 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:38 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:38 (1228) mediaoutput/mediaoutput.c:296:Master: 3.01, Local: 2.72, Diff: -286ms, delta: 7, new: 5
2018-10-30 07:27:38 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:38 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:38 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 63
2018-10-30 07:27:39 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:39 (1228) mediaoutput/mediaoutput.c:296:Master: 3.52, Local: 3.31, Diff: -207ms, delta: 5, new: 4
2018-10-30 07:27:39 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:39 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:39 (1228) mediaoutput/mediaoutput.c:296:Master: 4.01, Local: 3.85, Diff: -155ms, delta: 4, new: 3
2018-10-30 07:27:39 (1228) mediaoutput/omxplayer.cpp:154:Slowing Down playback
2018-10-30 07:27:39 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 0   frameNumber: 79
2018-10-30 07:27:39 (1228) MultiSync.cpp:1360:ProcessSyncPacket()   type: 2   filetype: 1   frameNumber: 0
2018-10-30 07:27:39 (1228) mediaoutput/mediaoutput.c:296:Master: 4.52, Local: 4.09, Diff: -426ms, delta: 3, new: 8
2018-10-30 07:27:39 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:40 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:40 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:40 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
2018-10-30 07:27:40 (1228) mediaoutput/omxplayer.cpp:157:Speeding Up playback
« Last Edit: October 30, 2018, 08:49:04 AM by pixelpuppy »
xLights and Vixen3 for sequencing / FPP for scheduling and playing / Falcon controllers for pixels / homemade controllers for everything else

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: FPP 2.3 now available
« Reply #33 on: October 30, 2018, 11:56:11 AM »
Dan,

I found something else that might be causing the swinging back and forth without hitting the target.
Code: [Select]
src/mediaoutput/mediaoutput.c

-  int desiredDelta = diff / -33;
+ int desiredDelta = diff / -50;

The delta step calculation in FPP mediaoutput was changed from 33 to 50.  As far as I can tell, the delta number is used to determine how many Speedup or Slowdown steps to make.   However, I dug into the omxplayer patch (written by MasterDaddy I think) and see that the speedup and slowdown steps are hardcoded at 33 in there.   So now, FPP's calculation on the number of Speedups/Slowdowns needed is going to be off from what omxplayer is doing, thus contributing to the swinging back and forth faster/slower/faster/slower.

I could be all wrong, I'm just trying my best to help with the diagnosis.  I think these three changes will help improve the media sync:
  • change delta steps calculation back to 33.  This matches what is coded within the omxplayer speedup/slowdown_micro patch
  • do not defer speed changes on 1st sync packet received, which delays startup by 2 sync packets (1 second)
  • send SyncMedia 0.000 packet immediately after StartSyncedMedia so first sync packet is not 1/2 second behind.
If there is anything else you want me to look at or try, I'm happy to do my best and hunt it down.

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: FPP 2.3 now available
« Reply #34 on: October 30, 2018, 12:13:37 PM »



I can definitely change back to 33, but that will result in larger "diff" values which could result in larger swings.   


Sending a SyncMedia at 0.00 won't do anything, particularly in your case.     I had to send a 0 frame for fseq sync because the remotes don't actually start outputting any channel data until it gets the first sync packet.  The "Start Seq" command is actually treated as a "Load Seq" and doesn't actually start anything.    The media start actually starts the media. 


I don't actually defer the speed changes on the 1st.  What is happening is that if the returned media position is <0.01 seconds, it assumed the media is not "running" yet.   Basically, we cannot speed up something that isn't running.   From an omxstandpoint, it won't accept the "speedup keypress" until it's acutally started outputting video.  If it takes more than 1/2 second to start up, the first packet is already irrelevant.  Adding another won't change anything.
Dan Kulp

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: FPP 2.3 now available
« Reply #35 on: October 30, 2018, 01:12:58 PM »
I can definitely change back to 33, but that will result in larger "diff" values which could result in larger swings.   
I didn't show it before, but that same code block contains another limiter that sets the max delta to 15 in the first 10 seconds or 5 any other time. That should be limiting the large swings.  I think having the delta divisor match the omxplayer speedup/slowdown value should make them be able to converge more accurately (not swing back and forth).  Here's the code block...

Quote from: github
   // Allow faster sync in first 10 seconds
   int maxDelta = (mediaOutputStatus.mediaSeconds < 10) ? 15 : 5;
   int desiredDelta = diff / -33;  // THIS MATCHES OMXPLAYER ACTION_INCREASE/DECREASE_MICRO
   int desiredDelta = diff / -50; 
    if (desiredDelta > maxDelta)
      desiredDelta = maxDelta;
   else if (desiredDelta < (0 - maxDelta))
      desiredDelta = 0 - maxDelta;


Quote from: dkulp
Sending a SyncMedia at 0.00 won't do anything, particularly in your case.     I had to send a 0 frame for fseq sync because the remotes don't actually start outputting any channel data until it gets the first sync packet.  The "Start Seq" command is actually treated as a "Load Seq" and doesn't actually start anything.    The media start actually starts the media. 
I hear what you are saying, but the debug log shows the first media sync at 0.52 with a local at 0.00 so it doesn't appear to have started yet (could be omxplayer startup delay - I don't know).  Also, I'm just guessing, is not sending a sync at 0.000 possibly related to the situation where I was seeing remote offsets in the 2-3 minutes off the master at sequence startup because they were carried over from the previous sequence and not "synced to 0" when the current sequence started?  Would it hurt anything to send a MediaSync 0.000?  From what you are saying, In most cases it should get ignored, but it might help in some cases.

Quote from: dkulp
I don't actually defer the speed changes on the 1st.  What is happening is that if the returned media position is <0.01 seconds, it assumed the media is not "running" yet.   Basically, we cannot speed up something that isn't running.   From an omxstandpoint, it won't accept the "speedup keypress" until it's acutally started outputting video. 
In the debug log I posted, the 1st media sync was sent by master at 0.52 and the local playback was still at 0.00. 
The 2nd media sync sent by the master at 1.01 with the local at 0.07.

So from what you're saying, omxplayer is triggered to start on the StartSynceMedia command without a time offset.  And when the first MediaSync arrives 0.52 seconds later, the player is still sitting at 0.00 even though it has already been commanded to start 0.52 seconds earlier?  Then the 2nd MediaSync sent from master at 1.01 with local playback sitting at 0.07.  So the omxplayer takes 0.94 (almost 1 full second) between when told to start and when it actually starts playing?   

If that's true, maybe the first 10 seconds should allow swings of more than 15 steps to recover from the 1-second startup delay much quicker?   Alternatively, I saw an option in omxplayer to set a start position.  Not the best solution, but maybe - just maybe - tell it to start at 0.5 or 0.75.  I realize that will crop the first few frames of the video, but that should start the playback much closer to master sync and might just be a better compromise if not allowing swings larger than 15 steps
« Last Edit: October 30, 2018, 01:30:06 PM by pixelpuppy »

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: FPP 2.3 now available
« Reply #36 on: October 30, 2018, 01:59:19 PM »



The patch that we do to omxplayer only allows 15 steps so we cannot go more than that without having to completely rebuild omxplayer again.  :(    There is a "2x" speed, but I haven't figured a reliable way to get out of it yet.


The omxplayer "start position" thing doesn't allow fractional seconds.  I tried that.  :(


The other option which will require quite a bit more investigation is to use dbus to communicate with omxplayer.   There are a bunch of "seek" commands that can be sent via dbus.   That said, that's a lot of work to flip over to using. 


A lot of the startup time depends on the mp4.   For hidef, it's a lot longer.  Thus, if you reduce your video down to 640x480 or so, it will likely start faster.   


Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: FPP 2.3 now available
« Reply #37 on: October 30, 2018, 04:30:30 PM »
A lot of the startup time depends on the mp4.   For hidef, it's a lot longer.  Thus, if you reduce your video down to 640x480 or so, it will likely start faster.
That's a good tip, thanks  :)  Currently my videos are all HD (1920x1080 or more) I wish the xLight House Preview Video export gave us more control over that  :-[  but I can re-encode them with 3rd-party tools.  Its an extra step for each sequence, but not horrendous  :-\


Quote from: dkulp
The omxplayer "start position" thing doesn't allow fractional seconds.  I tried that :( 
Did you try it with 1 second?  I wonder if that would be OK or too annoying/horrible  :-[  .  Probably not a good long-term solution but it would be an interesting test.  How does FPP launch omxplayer?  Is it a script that I can edit or is it buried inside compiled code?


Quote from: dkulp
The patch that we do to omxplayer only allows 15 steps so we cannot go more than that without having to completely rebuild omxplayer again.  :(    There is a "2x" speed, but I haven't figured a reliable way to get out of it yet.


Isn't that what the standard functions ACTION_INCREASE/DECREASE_SPEED do?  I was under the impression ACTION_INCREASE_SPEED does a "2x" and ACTION_DECREASE_SPEED does a "0.5x".   So if a single "increase" of 2x is active, then a single "decrease" of 0.5x should put it back to 1x (normal) speed.  At least that's how I read it.  ???


Plus, it looked to me like the fpp patch included 3 new functions: the two _SPEED_MICRO adjustments and ACTION_NORMAL_SPEED.  I wonder if that works to cancel 2x speed or only MICRO speed adjustments?  :-\

Offline ncosper

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 59
  • Kudos: 0
Re: FPP 2.3 now available
« Reply #38 on: October 30, 2018, 09:26:46 PM »
I went through and did an image update to all of my pi's today and just cannot get most of them to sync still. Its just a royal mess. I have one pi that does dmx output that I also have an mp4 play to which works great, all the others are often WAY ahead of the main song, then the main mp3 doesn't even finish the song. Normally ends a few seconds early. ...Here is my multisync page.
Tried all of these without the fseq and same thing. Tried uploading the fseq's in case it would help but it didn't.

Offline ncosper

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 59
  • Kudos: 0
Re: FPP 2.3 now available
« Reply #39 on: October 30, 2018, 09:35:22 PM »
If I roll the remotes back to 2.2 they work well. They stay about 1 second behind but one second behind is a ton better than the previous results.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: FPP 2.3 now available
« Reply #40 on: October 31, 2018, 08:12:48 AM »
A lot of the startup time depends on the mp4.   For hidef, it's a lot longer.  Thus, if you reduce your video down to 640x480 or so, it will likely start faster.
That's a good tip, thanks  :)  Currently my videos are all HD (1920x1080 or more) I wish the xLight House Preview Video export gave us more control over that  :-[  but I can re-encode them with 3rd-party tools.  Its an extra step for each sequence, but not horrendous  :-\ 

I converted the video from Full-HD to 1/2-HD (960x540) and it improved the startup delay from about 1 second down to about 1/2 second.  Then I tried 1/3-HD (640x360) with only a marginal improvement in startup time.  That is too low-res for me anyway, so I did't even try 1/4-HD.   ::) 

Also, I found the Windows Registry Key that is used to determine size of the xLights video export, so that saves me the step of converting them after export.  :)

Quote from: pixelpuppy
Quote from: dkulp
The omxplayer "start position" thing doesn't allow fractional seconds.  I tried that :( 
Did you try it with 1 second?  I wonder if that would be OK or too annoying/horrible  :-[  .  Probably not a good long-term solution but it would be an interesting test.  How does FPP launch omxplayer?  Is it a script that I can edit or is it buried inside compiled code?
I found the script in /opt/fpp/scripts so I experimented with using the --pos option.  It appears that not only does it not take fractional seconds, but if I enter 00:00:01, it starts at 2 seconds.  :o  So that's no help for this problem.  :(

Now that I've found the script that launches it, I think I can pull the un-patched omxplayer from the 2.1 image and use it just for my "indoor Show Monitor".  The non-speed-adjusted playback works much better for me in this case.  Since its scripted, I can add the logic to choose which version of the player to use depending on which remote its on.  Well, that's my current thinking anyway... ::)  ... probably will change my mind again tomorrow... ;D

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: FPP 2.3 now available
« Reply #41 on: November 01, 2018, 06:28:50 PM »
I noticed a something weird when a sequence first starts.  I grabbed a screenshot to show you.   Look at the timestamps on all the remotes.  They are WAY OFF.   They appear to start each sequences with times that are all different and 1-2 minutes off the master time.   It appears that sync playback it trying its best to get them back in sync, but its a struggle when they all start that far off.  I have no idea why that would start a sequence that far off each other, but it can't be good for multi-sync.  :o


Hey Dan,


Now that I know what's going on with Video sync and how to handle it, I need to re-visit this other problem/issue with you.  The large discrepancy in sync times between remotes.  Several minutes off in some cases.   It seems like the timer on the remotes carries over from a previous sequence.  Maybe some race condition between the previous sequence StopSync and the new sequence StartSync?   If you can clue me in on the best place(s) to look, I'll start digging



« Last Edit: November 01, 2018, 07:09:09 PM by pixelpuppy »

Offline mattyams

  • Newbie
  • *
  • Join Date: Jun 2017
  • Location: Atlanta
  • Posts: 12
  • Kudos: 0
  • SUPER ADMIN!
Re: FPP 2.3 now available
« Reply #42 on: November 02, 2018, 01:05:53 AM »
I had the same experience with the spinning circle after clicking upgrade.   After waiting a bit and refreshing, it did upgrade to 2.3 (from 2.1). 


My current issue is on a Pi with a matrix adapter with 2.3 the panel seems to start on channel 1 vs what's configured in the LED Panel configuration (22873).   Worked fine on 2.1 (didn't try on 2.2)

I'm have the same problem with my matrix adapter starting on a completely different channel. We're you able to get it straightened out?

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: FPP 2.3 now available
« Reply #43 on: November 02, 2018, 03:33:17 AM »
I had the same experience with the spinning circle after clicking upgrade.   After waiting a bit and refreshing, it did upgrade to 2.3 (from 2.1). 


My current issue is on a Pi with a matrix adapter with 2.3 the panel seems to start on channel 1 vs what's configured in the LED Panel configuration (22873).   Worked fine on 2.1 (didn't try on 2.2)

I'm have the same problem with my matrix adapter starting on a completely different channel. We're you able to get it straightened out?


That should be fixed on master.

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: FPP 2.3 now available
« Reply #44 on: November 02, 2018, 03:35:11 AM »

Now that I know what's going on with Video sync and how to handle it, I need to re-visit this other problem/issue with you.  The large discrepancy in sync times between remotes.  Several minutes off in some cases.   It seems like the timer on the remotes carries over from a previous sequence.  Maybe some race condition between the previous sequence StopSync and the new sequence StartSync?   If you can clue me in on the best place(s) to look, I'll start digging



Probably the same idea... turn on excessive logging for multisync on the remote and reproduce.  It should show the masters current frame so we can see if it's getting some rediculous number.

 

Back to top