feature request: override refresh delay

[theodiem]

It would be nice if a plugin could tell the cached screen to "refresh earlier" than the configured threshold.

My usercase: I have a day planner being displayed and contain certain elements that changes on specific times. For example the "current hour" digit is highlited (and the planner smallest division is 15 minutes, but lets keep it simple). If I leave the refresh to 900 seconds, if the screen is loaded at 09:56 , the highlighted hour would be "09" until 10:11.

When polling the URL for the plugin, I could add a "Expires" header. In the usercase above, if it gets polled at 09:56, the "Expires" would be set to 10:00 and the screen gets transmited to the device with a refresh of 4 * 60 seconds instead of 900.

It would be a nice way to avoid outdated information to be shown. In case of a playlist, it just moves to the next screen earlier and if it is a single item playlist, it would just refresh. In case of multiple polling URLs, just use the smallest "Expires" returned.
I have a playlist "sleep" (because I want custom sleep screens) that have refresh set to 3600. It would also be nice to avoid having to configure them to switch back to "main" one hour ealier, in order to deal with the screen be polled 1 minute before the sleep ends.

From what I understood in the trmnl, the firmware "sleeps" the hardware while it waits the refresh time to pass.

Still, I believe it should be a toggle option as many places set Expires to epoch or "now() -1" to avoid caching and also the configured device/playlist refresh to be used in case "Expires" sends a larger value.

[bnussbau]

I mean for time critical recipes you could set the Data is stale after minutes to 1 minute?

But yeah, I could add a per-recipe option to respect the Expires header.

[theodiem]

I mean for time critical recipes you could set the Data is stale after minutes to 1 minute?

My idea was a bit further than just making the backend "pool data again". Let's say I have a playlist with 1800 seconds refresh interval. So a screen will update at 09:18, 09:48, 10:18, 10:48. On every time a device "pulls" a screen (/api/display), it gets "refresh_rate"=>"1800".

If the plugin/backend that generates de data to be displayed "knows" that when 09:48 request comes in, it is "expired" at 10:00, would be nice to have /api/display in that request to have "refresh_rate"=>"720", so the device will wake up at 10:00 and refresh or move to the next screen. If the request would have received at 10:02, it would have "refresh_rate"=>"1800" as configured.

I see this feature as a way to be smarter about sleep screens (like "refresh in 4h" but "no later than 06:58 AM") and/or a way to "syncronize" multiple screens refresh (or avoiding it) by having one screen in a playlist "delaying or shortening" its visible time).

I'm not familiar with the internals in larapaper regarding "pre-generating" the screen image and caching it and how the device devices to pull a new image or not. In the little I've seen there are some condition like "if the image_url haven't changed, use the cached version" but the json data of /api/display is always parsed.

I'm not expecting a "solution" for subsecond granularity time syncronization. Just to dynamically balance between screen updates (flickering/battery) and "outdated information". My usercase is fine with 1800 refresh_rate if it wasn't the "hour change" and using 450 makes it too distracting

[theodiem]

While argumenting about the usercase, it ocurred to me if is there any way I can control when larapaper generates a new image or reuses an old one. For example if the output of the liquid template stays the same and if data from the POST stays the same, to point to the same image_url. If i'm not mistaken the device firmware doesn't pull a new image in this case (I haven't checked if it might not refresh/flicker the screen).

To me, it could be a temporary fix for the distracting flickering since I have a single item playlist through the day.

[bnussbau]

I've been thinking about this a bit more.

I agree that adding a toggle to respect the Expires header makes sense, especially when the backend has more accurate information about when the content becomes stale.

For time-based plugins (for example: clocks, calendar, weather, … that highlight the current hour) I think a toggle on a playlist item, like "Smart Scheduling" would be useful.

The server already controls how many seconds the device waits before polling again. If it knows that the next poll would happen at 9:58 and Smart Scheduling is enabled for the next playlist item, it could delay the next poll until 10:00 instead. This would keep the current playlist item visible a little longer and ensure that the next refresh happens as soon as the time-relevant information changes.

The scheduling could snap to an interval, such as the next quarter hour.