subwave-nowplaying/README.md

subwave-nowplaying

Tronbyt/Tidbyt app showing the current track on a SUB/WAVE internet radio station: album art, and four scrolling lines — track title/artist, a thin separator, the current show and host, and local time/temperature — plus a track progress bar pinned to the bottom of the 32px-wide text column. Color scheme (cyan title/artist, white show name, magenta host/progress bar) is loosely modeled on SUB/WAVE's own web now-playing display.

Not tied to any specific station — set your own station's base URL in the app's config when adding it to a device.

Configuration

• Station URL — the base URL of your SUB/WAVE instance, e.g. https://radio.example.com. No trailing slash needed (stripped automatically). No auth required — SUB/WAVE's now-playing and cover-art endpoints are public.

How it works

• GET {station_url}/api/now-playing — track title, artist, subsonic_id, DJ/station name, and stream online status. Cached 20s.
• GET {station_url}/api/cover/{subsonic_id} — album art JPEG, proxied by SUB/WAVE itself (no Navidrome credentials needed). Cached 300s.
• If the station reports streamOnline: false, shows " offline" instead of stale track info.
• If a track has no subsonic_id, or the cover fetch fails, falls back to a full-width layout with no art rather than a broken image.
• Shows the current show name (context.activeShow.name) and host name (dj.name) below the artist, separated by a thin divider line, and the local time/temperature (context.clock/context.weather) below that — all as independently scrolling Marquee lines, confined to the 32px-wide text column next to the album art (no overlay/overlap with the art).

Known quirk — occasional Marquee glitch: pixlet's render.Marquee runs its own internal scroll-cycle animation, and stacking several Marquees of different text lengths in one Root can occasionally desync them — a line may briefly blank or show a garbled frame while another Marquee is mid-cycle. This is a real, currently-unfixed pixlet bug (there's an open FIXME: Behaviour when children themselves are animated is a bit weird in pixlet's own widget docs), not something introduced by this app. It's also not unique to this app: tronbyt/apps/apps/goosefm/goose_fm.star (an accepted official community app) stacks 3 Marquees for the same kind of now-playing info and exhibits the identical occasional glitch on close frame-by-frame inspection. In practice it's subtle enough to be easy to miss on a real, continuously-scrolling display. A custom hand-rolled scroll (via animation.Transformation + Translate, avoiding Marquee entirely) was prototyped and could fully eliminate this, but only by consolidating down to 2 scrolling lines total (title alone, everything else combined into one line) — full independent lines for every field was preferred instead, accepting the same minor quirk real Tidbyt/Tronbyt apps already ship with.

Progress bar caveat: the now-playing API reports track duration but not elapsed/remaining time, so the app tracks playback position itself — the first time it sees a given subsonic_id, it stamps the current wall-clock time in pixlet's cache, then diffs against that stamp on later renders to compute elapsed seconds. This only works correctly on a long-lived server process with a persistent cache (true for tronbyt/server's in-memory cache) — a one-shot pixlet render CLI invocation always starts a fresh process with an empty cache, so the bar will always show 0% when testing locally. This is expected, not a bug.

Note on unreachable hosts: if the station URL is wrong or the host is completely unreachable (DNS failure, connection refused), http.get raises a hard error and the render fails for that cycle — this is normal pixlet/ Starlark behavior (no try/except in the language), not a bug. Only HTTP-level errors (404, 500, etc.) are something the app can catch and display a message for, which it does.

Dev/test

pixlet render subwave_nowplaying.star station_url=https://your-station.example.com
pixlet serve subwave_nowplaying.star

Deploy

Upload subwave_nowplaying.star directly through your Tronbyt server's "Upload app" button on a device's Add App page (single file, no bundled assets — no need to zip). Configure the Station URL field when adding it to your device's schedule.