Author Topic: FPP 2.5 Now Available  (Read 7373 times)

Online th182

  • Newbie
  • *
  • Join Date: Dec 2015
  • Location:
  • Posts: 47
  • Kudos: 2
Re: FPP 2.5 Now Available
« Reply #105 on: December 12, 2018, 11:26:08 AM »
The logs aren't detailed enough when running at the current log level, we would need to see Debug level logs for the Scheduler and Playlist to really see what is happening.  I can take a guess though.  It looks like your "Show Start" playlist from 15:30-15:35 is set to repeat.  I think that is likely the issue if this playlist only contains non-repeating LeadIn entries.  I was looking into an issue with this scenario last night and have a note on my ToDo list to work on a fix.
Thanks for the quick help! I changed them to not repeat and we will see if it runs today. I also changed the log-level.. I overlooked that dropdown!

Are you using ZoneMinder?  I've been thinking about doing the same thing in my setup, but haven't had a chance to do it yet.  For now, I temporarily disabled motion detection on the affected cameras since I haven't looked up how to use the different profiles in ZM.
I am using Blue Iris so I use a URL to change from my default profile to a Holiday Lights one that disables motion alerts on my front yard cameras.

Online th182

  • Newbie
  • *
  • Join Date: Dec 2015
  • Location:
  • Posts: 47
  • Kudos: 2
Re: FPP 2.5 Now Available
« Reply #106 on: December 13, 2018, 03:57:39 PM »
Thanks captain! Show has been running solid the last two nights!


Sent from my iPhone using Tapatalk

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: FPP 2.5 Now Available
« Reply #107 on: December 22, 2018, 02:08:38 AM »
When my FPP 1.8 install went haywire presumably from losing power (i.e. not using FPP's Shutdown command) and not being able to get 1.8 to install again, I decided to install 2.5 fresh, but I seem to have found a bug.


I'm running a Raspberry Pi 3 with PiHat from Crockett Fantasy of Lights which is used for our living room Christmas tree to run about 400 pixels on it. Under Channel Outputs, under Pi Pixel Strings, they are set as an RPIWS281X output. I made a sequence in xLights about 2 minutes long with varying blended effects. It starts with all white and ends with all white so when it loops, it looks seamless. When I went into the status page to run the sequence manually (versus the Scheduler that would be used to make it run on a daily basis) without using the Repeat option, when the sequence finishes, all lights on the tree turn off except for the first 15 that usually remain on (but not always). I haven't run it on a schedule yet to see what happens in that situation; that is, if the 15 pixels would remain on at 11 PM every night when the tree is supposed to turn off. Enabling and disabling the Display Testing screen's Test mode turns the stray pixels off. Speaking of the Display Testing feature, when I use the Sequence tab to run the sequence from start to finish without interruption, it doesn't seem to have the problem with the stray pixels being left on at the end.


I did also notice that when I use the Display Testing feature under the Channel Testing tab and turn the Enable Test Mode checkbox on and off to start and stop the light test, the portion of the tree with the first pixels seems to lag behind the rest of the tree. It's not a huge lag--less than 1/20 of a second I'd guess--but I notice it.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,293
  • Kudos: 37
Re: FPP 2.5 Now Available
« Reply #108 on: December 22, 2018, 08:31:18 AM »
When I went into the status page to run the sequence manually (versus the Scheduler that would be used to make it run on a daily basis) without using the Repeat option, when the sequence finishes, all lights on the tree turn off except for the first 15 that usually remain on (but not always). I haven't run it on a schedule yet to see what happens in that situation; that is, if the 15 pixels would remain on at 11 PM every night when the tree is supposed to turn off. Enabling and disabling the Display Testing screen's Test mode turns the stray pixels off.


I would try enabling the "Always transmit channel data" checkbox in FPP Settings.    By default, when FPP stops playing a sequence, it also stops outputting data.  Some controllers and some pixels are unpredictable when there is no data signal.  Keep in mind that "no data" is not the same thing as "zero data".   Pixels need to see Zero's (000000) in order to turn off.   If you enable the  "Always transmit channel data" checkbox, the FPP will output continuous zero's when there is no sequence playing.  This helps keep the lights off for controllers and pixels that are more susceptible  when there is "no data".
-Mark

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: FPP 2.5 Now Available
« Reply #109 on: December 22, 2018, 11:03:39 PM »
I would try enabling the "Always transmit channel data" checkbox in FPP Settings.    By default, when FPP stops playing a sequence, it also stops outputting data.  Some controllers and some pixels are unpredictable when there is no data signal.  Keep in mind that "no data" is not the same thing as "zero data".   Pixels need to see Zero's (000000) in order to turn off.   If you enable the  "Always transmit channel data" checkbox, the FPP will output continuous zero's when there is no sequence playing.  This helps keep the lights off for controllers and pixels that are more susceptible  when there is "no data".


Yes, that seems to have worked around the problem.

Offline lrhorer

  • Sr. Member
  • ****
  • Join Date: Feb 2015
  • Location:
  • Posts: 262
  • Kudos: -12
Re: FPP 2.5 Now Available
« Reply #110 on: December 23, 2018, 06:38:57 PM »
It's not exactly a work-around.  It is by design intent.  The pixels work by maintaining whatever state their last instruction directed until the next instruction comes along.  If the last instruction happens to be lit, then the pixel stays lit until a new instruction comes along.  Unless the controller sends out blanking signals, the lights will remain in whatever state they were at the end of the sequence.  If one does not wish to send out blanking signals after each sequence, then one must explicitly blank the display as the last instruction in the sequence, or else leave the display in its final state until power is removed or a new sequence runs.

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: FPP 2.5 Now Available
« Reply #111 on: December 25, 2018, 02:29:33 PM »
I assumed it was a bug and called it a workaround because if my sequence starts and ends with the entire tree being a solid white to make the loop seamless, and if the pixels are supposed to remain at the state at the end of the sequence, I would have thought that the entire tree would remain lit. In my situation, only the fist 15 pixels remained on.

It's not a big deal either way, but I thought I'd mention it.

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,504
  • Kudos: 192
Re: FPP 2.5 Now Available
« Reply #112 on: December 25, 2018, 10:44:28 PM »
The only thing I can think of is maybe this is a race between the last frame of data going out and the blanking data going out, but I have never seen anything like that happen.  If the lights are blinking correctly then the channel numbers would seem to be correct.  We blank all channels even if we are only reading a small range from the .fseq file with Dan's new code.

Can you zip up the .fseq file and email it to me and I'll take a look when I get a chance just to see if there is anything odd about it.
-
Chris

 

Back to top