Background Lighting and Integrations
Background lighting can keep useful information visible while the musical show changes. Integrations can report show status or coordinate other playback devices. Add either feature after the basic song, controller and schedule workflow is reliable, so the new behavior is easy to recognize and test.
Give the background a specific job
EZPlayer’s background schedule runs another playlist alongside the main show. Good planning candidates include a tune-to message, parking guidance or a short instruction loop. In the schedule editor, switch between foreground and background with FG / BG; background entries have their own timing and playlist choices.
Version check: the manual says versions 0.6 and earlier display Overlay and Underlay but ignore that selection and blend the schedules. The release reviewed for this guide is v0.6.12. Do not rely on the displayed selector to isolate foreground and background pixels in that release family.
Official reference: Background schedule and version limitation; v0.6.12 release.
Build a small, observable background test
Mattos recommends assigning the first background sequence to a dedicated informational model and keeping the main test sequence black on those same channels. This reduces overlapping content while you verify the result; it is a test strategy, not a claim about a hidden blend algorithm.
- Create a short background loop with an obvious, readable message. Review its channel coverage before rendering.
- Register it and place it in a dedicated playlist with an unmistakable name.
- Create a short background window and a main-show window that overlap during supervised testing.
- Watch the sign during a bright song section, a dark section, a song transition and the end of each window.
- Check the physical result from the audience position. Simplify any competing content before extending the operating hours.
Decide what should happen when the background starts before the music or continues after it. The main schedule’s finish and interruption behavior still matters. Use the scheduling guide to review time windows, priority and end behavior, then test the actual combination.
Official reference: Schedule behavior and options.
Audio level can have a separate operating plan. The volume controls provide a default level and scheduled adjustments; a lighting background does not, by itself, establish quiet hours. See audio and show-night operations for the listening test.
Official reference: Volume controls.
Start automation with a read-only check
EZPlayer exposes an HTTP API. Use the actual listener address reported by the player; the normal starting port is 3000. For a first integration, read status before attempting commands that change playback or settings.
Scroll sideways to see all columns.
| Request | Use | Interpretation |
|---|---|---|
GET /api/ezp/hello |
Check that the server responds | A successful health response does not test physical pixels. |
GET /api/ezp/current-show |
Read show data and reported status | Some worker status objects can be absent immediately after startup. |
GET /api/ezp/playback-settings |
Inspect current playback settings in v0.6.12 | Use the documented version-specific response rather than guessing fields. |
For example, an operator on the show network can inspect http://<player-address>:<actual-port>/api/ezp/hello. Replace the placeholders with the player’s reported values. Keep automation inside trusted operator access; the local server does not provide authentication.
Official reference: API reference; Local web interface; v0.6.12 settings API additions.
Write integrations should have a clear scope: what triggers the action, what it changes, and how an operator stops it. Test against a spare show folder first. Avoid treating repeated commands as harmless; a command can affect the live song or schedule.
Do not edit EZPlayer’s JSON state files while the application is running. Its in-memory state can overwrite those edits. Use supported interfaces for live changes, and keep a recoverable backup before experimenting.
Official reference: Player data files.
Use FPP compatibility for a defined job
EZPlayer implements a documented subset of FPP-style HTTP endpoints. It is not a blanket guarantee for existing FPP tools: playlist conversions can lose structure, and unsupported calls may fail. Check the specific endpoint and examine any returned warnings before trusting an automated migration.
EZPlayer can also be an FPP MultiSync master, with compatible FPP or xSchedule remotes following its timing. It does not act as a sync remote in the documented implementation. The feature starts disabled, and the network should have one master.
The current implementation can send media sync alongside sequence sync. Review Send audio sync too when deciding which device should play sound. Test the remote’s content and audio path independently, then test synchronization; matching timing messages alone are not an acceptance test for the whole remote system.
Official reference: FPP compatibility and MultiSync.
Keep optional services optional
Choose an integration because it solves a particular show need. Use viewer control for audience requests and Remote Falcon, the cloud guide for EZRGB delivery, and direct status reads for a custom operator dashboard. None of these choices changes the need to verify controllers, media and schedule behavior on the real display.
Review the official release notes before updating a working integration. Record the version you tested and repeat the affected checks after an update, especially background blending, request handling or synchronized audio.
