Request For Enhancement: Enhance App Schedule Configurability

[RobotSail]

Weighted / Priority-Based App Rotation (RFE)

Background

• Rotation lives in tronbyt_server/routers/manager.py (create_expanded_apps_list, _get_app_to_display, next_app_logic). Apps are ordered, then an optional interstitial is inserted between each app; the index increments and wraps.
• Pinned and night-mode apps bypass rotation. Interstitial apps always show between regular apps when enabled.
• Eligibility is time-based in tronbyt_server/db.py::get_is_app_schedule_active_at_time (legacy day/time window or custom recurrence). It only gates whether an app can run; it does not change how often an eligible app appears within a cycle.
• There is no notion of per-app priority, weighting, or “every Nth cycle.” Reducing frequency today means disabling/reordering apps or using calendar rules, which either lengthens the loop or removes apps outright.

Problem / Goal

• Users want important apps (e.g., transit, clock) to appear every cycle, while low-priority/alert apps should surface intermittently (e.g., every 3–5 cycles) without lengthening the overall loop or juggling enable/disable states.
• Need cycle-level frequency controls that preserve ordering expectations and existing interstitial behavior.

Proposed Approaches (choose or combine)

1. Per-app cycle weight (duplicate entries in the rotation list before interstitial insertion).

   • Pros: deterministic order; simple mental model (“weight 3 shows 3x per loop”); minimal new state.
   • Cons: increases loop length for everyone; interstitials become denser; changing weights likely requires last_app_index reset or remap to avoid index mismatch.

2. Every-Nth-cycle inclusion per app (skip unless cycle_counter % N == 0), with a device-level cycle_counter stored alongside last_app_index.

   • Pros: keeps the loop short; directly expresses “rarely, but in order.”
   • Cons: needs persistent cycle counter; adding/removing apps mid-cycle can shift perceived cadence; must decide when to increment the counter (per full loop vs. per app advance).

3. Weighted random pick per slot from eligible apps (optionally “no immediate repeats” plus a minimum-gap guard).

   • Pros: flexible distribution without ballooning loop length; adapts automatically as apps enable/disable.
   • Cons: non-deterministic order may feel jumpy; needs starvation protection; interstitial placement rules get trickier.

4. Multiple interstitial apps (allow a list of interstitials that always play together between regular apps, e.g., MBTA + clock as a mini-block).

   • Pros: very simple mental model; effectively pins a short bundle between every regular app without touching the main order; deterministic.
   • Cons: lengthens every gap between regular apps; still no way to make a regular app appear less than every cycle; needs UI for ordering the interstitial bundle.

UI/UX Sketch

• App configuration: optional fields like “Priority weight (>=1)” and/or “Show every Nth cycle,” with helper text; defaults preserve current behavior.
• Keep calendar/time recurrence untouched; clearly label this as cycle-based frequency, not scheduling.

Open Questions

• If both weight and every-N are set, which wins? (Precedence vs. mutual exclusivity.)
• Should interstitials respect weighting or remain 1x between regular apps?
• How to order multiple interstitial apps if supported, and should they allow weighting/skip rules themselves?
• How to handle last_app_index migration when weights change—reset vs. map old indices?

Acceptance Criteria

• Default config preserves today’s rotation.
• Eligible apps can be made more or less frequent without altering dwell time or calendar schedules.
• Interstitial behavior is defined and documented under the new scheme.
• Tests cover cycle selection with weights/every-N, including pinned/night-mode and interstitial cases.

[IngmarStein]

Is this a duplicate of #554?

[RobotSail]

@IngmarStein Yes, closing in favor of this one.

[kit-repo-depot]

Another approach for interstitial apps could be to configure how often the interstitial app showed, e.g. if I want a clock to be guaranteed to be displayed in every minute, on a 15s timer it would be every 3rd app and the rotation would be app -> app -> app -> interstitial -> app and so on. Combined with approach 4 you could mitigate one of the cons by lowering the overall portion of a cycle dedicated to interstitial apps.

[RobotSail]

@kit-repo-depot That approach could work, how would you make it work for 2 or more apps though? For example if I want a clock, travel times, and upcoming meetings?

[kit-repo-depot]

I'm not sure on the GUI side, but I think the data model would need to be changed in internals/data/mdoels.go to allow InterstitialApp to take a list value, like Apps does. It also looks like parts of the rotation logic would need to change to support different interstitial frequencies as well as multiple apps, though I'm still poking through the logic here.

As a side note I've been setting up seasonal scheduling with systemd timer units and the API, and it looks like the handlePatchDevice function in internal/server/handlers_api.go is missing a switch for the interstitial app, so while I'm messing with that on my local build I'll try to hack around some ideas for multiple interstitial apps/variable interstital frequency

[RobotSail]

@kit-repo-depot I've actually already implemented a solution for this issue, but it didn't seem like the project maintainers were interested in adopting it. I'd need to rework it for Go, but the functionality is very simple: https://www.loom.com/share/d26119bbc685425fb85777cad71fbcbf

Probably you could implement something similar if you wanted to take a stab on it. Would be super helpful to have!

[IngmarStein]

@RobotSail which PR was that again?