Server migration complete, Welcome to version 2.1.1



Welcome, Guest.
Please login or register.
Forgot your password?

+-Site Stats

Total Members: 15649
Latest: zj023
New This Month: 53
New This Week: 12
New Today: 0
Total Posts: 128316
Total Topics: 15780
Most Online Today: 53
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 4
Guests: 21
Total: 25

FPP 5.5 Released!

Started by dkulp, January 20, 2022, 01:13:15 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


FPP 5.5 Released!

This is mostly a bug fix release to fix issues encountered with Christmas shows, but it also contains some other enhancements.

Note: There are no OS level changes. OS level will remain at 5.3.

  • Enhance the scheduler to allow scheduling repeating FPP Commands
  • Restarting FPPD when a scheduled playlist is running will restart at the same item
  • Open links to remotes from Multisync page in new tabs
  • Remember MultiSync filters to avoid having to reenter each time
  • Allow deleting a corrupt Playlist from the Playlist list UI
  • Enhancements to Channel Testing page to allow easier selection of channel ranges
  • Added robots.txt to protect exposed FPP instances from being listed on the usual search engines (although exposing FPP is a bad idea)
  • Add multi arch support to docker for both amd64 and arm64
  • Add to warning if UDP output is set to self
  • Updates for floating player controls

Bug Fixes
  • Fix problems if scheduled entry start and end times were equal
  • Fix "Insert Playlist" commands not working correctly to insert an entire playlist
  • Fix problem of extended playlists that stopped gracefully may restart instead of fully stopping
  • Fix Script Editor Save/Cancel buttons
  • Allow hostnames in universe IP fields
  • Fix a bunch of place that did not allow start channels above 1M
  • Allow DDP outputs to have more than 512K channels
  • Don't show the second 12:00 AM when not in 24-hour format
  • Fix second-midnight not working in scheduler UI in 12-hour mode
  • If the user starts a playlist manually that is supposed to be running via the scheduler, use the scheduler to start the playlist so that it stops at the scheduled end time.
  • Several playlist randomization bugs are fixed
  • When jumping to another position in the currently scheduled playlist, don't reset the schedule so the playlist will end on time.
  • Fix range/volume sliders not displaying correctly in Firefox/Edge
  • Fix playlist editor losing playlist durations

Installation Instructions
If you have a system running 5.x, you can go to the FPP about page (about.php) and click on the "Manual Update" button. At that point, a big green "Upgrade" bar should appear on the main status page. Click on that to start the update process. It may take a long time to upgrade. Likely 5-10 minutes. You will need to reboot after the upgrade is complete to finish the upgrade process.

For users of FPP 4.x or older, it is strongly recommended to do a full "OS Level" upgrade or re-image instead of attempting to upgrade directly from any older FPP version. There are several new features that will not work if an OS level upgrade is not done. There are two ways to do so:

  • Re-image - you can backup your 4.x configuration, create a new image, and restore the configuration.
  • In-place upgrade - this is new and requires you to have FPP 3.6.2 (or 4.0-alpha2) or newer already running on the device. Download the appropriate "fppos" file to your computer. Make sure the file extension is still fppos (some browsers will rename it). Upload it to the "File Manager" on the FPP instance. Then go to the about page. Under the normal "Manual Upgrade", a new Upgrade OS button should appear. Click it and wait a LONG time. When done, it should reboot into 5.0. At that point, go to the Uploads tab of the FPP File Manager and delete the fppos file. Note: In SOME cases, the reboot will fail due to library replacement. In that case, a power cycle may be required to get it back up and running.

Selecting an image
For Raspberry Pi series including Pi B, Pi B+, Pi 3, Pi 3+, Pi 4 and Pi Zero use this image

For Beaglebone Black, Beaglebone Green, PocketBeagle, and Beaglebone Green Gateway use this image
Daniel Kulp -


While doing some testing with the new 5.5 version, I can into a small error that appears to be something minor as if something is out of order.
During the boot sequence and logged into the browser page, I get a Quick Red Message:

Abnormal Conditions - May Cause Poor Performance 
FPPD Daemon is not running

You cannot view this attachment.
You cannot view this attachment.


Quote from: breese on January 27, 2022, 10:57:00 AMWhile doing some testing with the new 5.5 version, I can into a small error that appears to be something minor as if something is out of order.

That happens because you opened the web page before the fppd daemon finished starting up.  We could delay the web server before fppd starts, but having it enabled lets you know the system is up.  I believe it has worked this way since we enabled that warning.


I just did an upgrade from 4.6 to 5.5 and am having a problem with my P5 display, I did not have this problem running under version 4.6. I have a master pi3b running in my house with a TP link AC1750 on a subnet different than my home wifi and 3 raspberry pi's outside in the yard one is in the case with my P5 panels. After the upgrade it looked like everything was working fine until I put the Pi in the P5 case in the test mode on a fill color (any color) it was then I saw the brightness of all the panels flashing (going dim) about 10%-15%. I replaced all the electronics in the display and even built up another 1 panel display using all new parts and got the same flashing. After three days of trouble shooting what I found was if I shut down Firefox on my desktop, that I was using to test the setup, in the P% display the flashing went away, so I fired up my Dragon Touch 10" pad and started Chrome and shut down my desktop the flashing started up again. At this point I am at a loss as to what could be causing this problem, again I did not have this problem the last two years with the same hardware using V4.6 until upgrading to 5.5 after the 2021 Christmas season. I do not have any computers on the line during the running of the show which at that point stops the flashing, but can't figure this problem out.,
Thanks for any help on this minor glitch.



Did 5.5 get a lot pickier about the state of E1.31/Artnet/etc outputs? I've noticed on two occasions since upgrading to 5.5 that it has decided to stop sending data to my single output because that output has stopped responding to pings.

It so happens that my output had stopped responding to pings, but that's working as intended. My setup draws some amount of power when "off", so I have a timed switch that turns everything off at the outlet when I know nothing is meant to be running. It then turns everything back on at the appropriate time. The FPP, on the other hand, is just a Pi, so it runs 24x7. The playlist kicks in at a fixed time in the evening, then the switch turns on later based on sunset. Later in the night the process reverses itself. This all worked fine in 5.4. The FPP would happily send its UDP off into oblivion until the pixel stick turned on, and the pixel stick would happily start receiving the data at that point.

Starting in 5.5 the FPP seems to have gotten a lot more helpful (maybe in some cases, but not in mine), and is more aggressive about disabling apparently-dead outputs. Is this intentional?

What's the best way to disable this behavior? Unchecking the "monitor" box for the output? I don't mind if it monitors the outputs - I just don't want it to do anything with the results aside from putting a banner up on the web interface.


Quote from: simmonmt on February 06, 2022, 05:36:48 PMDid 5.5 get a lot pickier about the state of E1.31/Artnet/etc outputs? I've noticed on two occasions since upgrading to 5.5 that it has decided to stop sending data to my single output because that output has stopped responding to pings.

I ran into the same issue with my master so I looked into it tonight and was able to find and fix an issue that was causing this as well as another related to re-enabling the disabled controller.  I've fixed the primary issue in the master branch and am discussing the re-enabling fix with Dan to see which one of two options we'd prefer.  For now, you can disable monitoring and restart fppd to clear the cache.


I have attempted to install 5.5 several times.  Everything goes well until I try to upgrade to the latest release.  The installation from the image brings up v5.4.1.  (Odd, that, since it is supposed to be 5.5.)  When I upgrade, the version shows 5.4.1-1-g1799d6ed, and the local and remote git versions match (1799d6ed).  At this point an orange (and very annoying) banner pops up saying Version 5.5 is available.  If I click on the <Upgrade> button, the web page goes blank white, and nothing I try will recover it.  The console locks up completely.  I can get in via ssh, but that doesn't help, much.

This on a Raspberry Pi Zero W.


You know, I was so busy with other things, I didn't even notice the player won't play any sequences.  In addition, the CPU utilization is almost at 100%.


Quote from: lrhorer on June 20, 2022, 08:24:00 PMYou know, I was so busy with other things, I didn't even notice the player won't play any sequences.  In addition, the CPU utilization is almost at 100%.

From the ssh session (using 'top) or the FPP troubleshooting page, you can identify what process is using all the CPU.  I don't know how much attention this will get though.  We are heads-down working on FPP v6 which we are trying to release within the next month or so and aren't devoting much time at all on v5.5 any more.  We have a lot of people running v5.5, so this isn't a widespread issue and could be hardware or SD related on your system.  You could look at the syslog and messages logs in the Logs tab of the File Manager and see if anything shows up there.  Also the fppd.log.  The 100% CPU usage could also be FPP compiling and that would explain why you can't play anything.


The odd thing is top did not show much.  It may have been the FPP utility that was reporting incorrectly.  I finally installed 5.5 on a Pi 3 and then transferred to the Pi Zero W.  This worked just fine.  FPP now shows 86.67% CPU utilization, which is much better, but still pretty high, and top shows nothing of the sort.  It's showing about 96% idle.


Just loading the CPU utilization in the UI can cause load on a single-core system like that because it involves Apache, PHP, etc..  Running a tool from the CLI will give a much better representation of actual CPU utilization.  At idle, CPU utilization should normally be very low, even on a single-core Pi or BBB.


Yeah, at idle it is running about 4% - 6% according to top.  When running a sequence with no audio, it's around 10%.  That is plenty of headroom.

Support FPP

+- Recent Topics

help getting started, next step? by netfan
Today at 08:28:31 AM

Trying to configure LOR CF50D Floods on FPP Pi Player with PiCap by
Today at 08:20:12 AM

wifi issues on BBB running fpp v6.3 by bert-nc
Today at 07:50:51 AM

BBB / FPP sending data to ESP32 WLED by srwmemphis
Today at 04:39:02 AM

raspberry PI 3 / PI 4 by mrfix1
January 27, 2023, 07:13:55 AM

Bug in newest release by tbone321
January 26, 2023, 06:14:26 PM

Cannot Connect to F48V4-NS Through Rasberry Pi by Poporacer
January 26, 2023, 03:13:43 PM

new piCaps in the works? by Bwinter
January 26, 2023, 11:25:32 AM

DIY voucher request by CaptainMurdoch
January 26, 2023, 11:14:38 AM

Which volume to grow during setup? by RickR
January 26, 2023, 09:55:17 AM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod