Feature Requests

[synergy34]

Hello Again!

Do we plan to implement the following?

• Live Monitoring of the Device(s).
• Automation via Scripting.
• Ability to select Multiple Displays and perform an action.
• REST API.
• Client Crash Dumps saves to the Server. Alongside with the ability to send Emails for any important event.
• Automated UI Color based on Browser settings? (Automatic Light/Dark Mode)
• Ability to hop back and forward through videos via buttons on the remote.
• Material Design Theming.

Hope this helps. May update this with more.

[dimitrow7]

I had mentioned it in our Discord disco, but I'll post it here for more traceability.
As a functionality it would be great to have Single Sign-On support with OAuth 2.0 or OpenID Connect.

[514sid]

Hi @dimitrow7,

Are SAML and OIDC enough to cover most SSO use cases today?

[dimitrow7]

Hi @514sid and thanks for the feedback. Directly to the reply - yes, at the moment, to my knowledge, the two standards are quite sufficient. Especially for the case where I envision using the system in conjunction with my WP site via SAML (my site as SAML IdP and your platform as Service Provider (SP)) - this is perfectly sufficient.

[514sid]

Created a separate topic for SSO discussions:

https://github.com/orgs/screenlite/discussions/22

[514sid]

Hi @synergy34

Live Monitoring of the Device(s).

If you mean the ability to see the current device status (e.g., whether it's connected to the CMS), device storage, RAM usage, etc., then yes, this is core functionality.

Automation via Scripting.

Could you please clarify what you mean?

Ability to select multiple displays and perform an action.

Yes, this feature is planned.

REST API.

The entire application will be based on an API. You’ll be able to use the CMS with our frontend, or just use the CMS API endpoints directly. The backend and frontend will not be tightly coupled.

Client crash dumps saved to the server, along with the ability to send emails for important events.

Can you provide some examples of possible crashes? In general, the player (client) app can crash due to bugs, in that case, yes, I plan to log such events. If the crash is due to the host OS failing, it becomes more complex and would require a deeper understanding of each platform.

For example, I’ve encountered a case where the device ran out of storage. On Android, when this happens, the system becomes unusable, so we probably wouldn’t even be able to even send an alert.

Automated UI color based on browser settings (automatic light/dark mode)?

Initially, there will only be a light theme for the frontend. Once we have a stable version that covers the most basic needs, it shouldn’t be a problem to add dark mode support.

Ability to hop back and forward through videos via buttons on the remote.

The current concept for the player is to provide deterministic playback based on context (schedule, events, etc.). Manual control of players isn’t really a common use case for digital signage. However, if you can share this use case in more detail and visualize how the logic should work, we can definitely discuss it further.

[514sid]

And do we plan to cover all TV OS platforms? (AndroidTV/Google TV, WebOS, Tizen)

Android, yes. As for consumer-grade TVs running WebOS and Tizen — no, at least for now. Support for commercial TVs running WebOS and Tizen depends on the vendors, since both operating systems require developer authorization afaik.

[514sid]

Do we plan to have them in Lovelace cards with a Live view of what's being played on the device similarly to how Jellyfin does it with Active Devices in the Dashboard?

Yes.

Also how do we plan to manage power scheduling?

On Android (and other platforms), it is not possible via software alone to power on a device if there is no such firmware/hardware option. Once the device is powered off, no software can run, including apps, because the operating system is inactive. Turning the device back on is only possible on hardware that supports such functionality and exposes the relevant API to the OS or apps.

Correct me if I'm wrong. If you have examples that show the opposite, they would be helpful.

[514sid]

This is so that if the TV (or whatever) is being used, can be controlled the Receptionists without a computer and I.T intervention.

The closest option I can think of is using web apps. I’m planning to expose an event system API — for example, to trigger a specific playlist or pass data to a web app. However, this is still in the draft stage. The current focus remains on the primary use case: context-based (mostly schedule-based) playback.

[mr8791]

Also how do we plan to manage power scheduling?

On Android (and other platforms), it is not possible via software alone to power on a device if there is no such firmware/hardware option. Once the device is powered off, no software can run, including apps, because the operating system is inactive. Turning the device back on is only possible on hardware that supports such functionality and exposes the relevant API to the OS or apps.

Correct me if I'm wrong. If you have examples that show the opposite, they would be helpful.

Hey!

Have you thought of utilising Wake on LAN?

[514sid]

Hey!

Have you thought of utilising Wake on LAN?

Hi @mr8791

I'm curious how you see it fitting into a digital signage setup (CMS + player). For example, if a screen needs to be turned on remotely, what device would you expect to send the Wake on LAN packet? Would that device also be running Screenlite?

If so, how would that device itself be powered on in the first place to send the WOL signal? Just trying to understand the full flow you're imagining.