Feature Request: Apps can set their own relative duration

Currently some apps are terminated before they have finished displaying their information. This is often a problem for the News apps when it moves on to the next app before the headline has finished scrolling. While some static apps only need to display for a few seconds to communicate their information (e.g. Crypto price apps) some could benefit from displaying until they have finished displaying what they want to show (e.g. scrolling headline)

It would make sense if Apps could specify their own relative duration, perhaps as part of the .webp filename that is sent to the device. The developer could optionally create variants that fit within different durations that are sent according to the app cycle speed selected by the user. The developer could then adjust the animation/transition speed of the app for each variant to ensure it completes within the allotted time.

For example, a static app (e.g. crypto price) might have variants that are:

Normal: 10s
Quick: 8s
Turbo: 7s
Plaid: 6s

Whereas an app that conveys a lot of information (e.g. news headline, trivia app) might have variants that are all displayed for a big longer:

Normal: 15s
Quick: 12s
Turbo: 10s
Plaid: 8s

The developer could specify the duration for each user-selected speed “level” and then adjust the animation/scroll speed to ensure the information being conveyed fits within the allotted time.

This would prevent data from being cut off before the next app is displayed.

I would love to see per-app time specification, but as a free-form entry, as sometimes I wouldn’t mind keeping the weather (for example) display for as long as (gasp) 1 minute. :slight_smile:

1 Like

Yes. agree that would be awesome… I wound up putting two subway apps for the same station together to make it display longer, but an in app selection would be great…

2 Likes

I prefer the idea of developers optimizing variants of their apps for the four different speeds, rather than letting the user specify how long they want each individual app to display for. The former is more elegant and makes for a cleaner experience for the user.

2 Likes

would be awesome if there is a signal that can be sent to tidbyt that the app has finished rendering ( + a custom buffer timer) and then the cycle can continue. of-course there has to be a max-time limit in case someone accidently did not send the app finish signal.

This would be great if the asyn responses from the server are taking longer. In the begining, I remember that the server was taking longer to respond for the startup and my tidbyt was stuck in a restart loop.

2 Likes

Agreed - I think building in the ability for the news app to understand when it’s finished displaying the entire headline would be most useful. I set my cycle speed to ‘Turbo’ and other apps are fine, but headlines are almost always cut-off.

1 Like

Scrolling speed of text needs to be adjustable. It’s too slow right now.

The official display times are currently:

Normal: 15s
Quick: 10s
Turbo: 7.5s
Plaid: 5s

The point is to allow app developers to be able to override these times based on the information they are displaying.

I concur that this should be set at the individual app level, or at the very least have a number slider that we can manually set a cycle time. I’m developing an app that cycles through content which take about a minute, and is always cut off after 15s.

1 Like

“At least once” (with a buffer per ptewari) would solve this, at least for me.