Show the current Spotify track on the speaker display (same opt-in as radio ICY)

[sskubic-eng]

Setup: Wave SoundTouch IV (variant lisa, module sm2), firmware 27.0.6,
STR v0.9.58. All six presets are Spotify playlists, recalled from the IR remote.

What happens now: the speaker's display shows the preset name — e.g.
"All BTS Songs (In Order and Updated)" — for the whole listening session. The
track never changes on screen, even as the playlist moves through songs. The
correct track does show in the desktop app, so the data is clearly there.

The ask: wire the Spotify per-track callback into the display push that
already exists for radio, behind the same opt-in setting.

Why this looks like a small change from the outside:

• spotify.Manager.SetOnTrack already fires on every track change — it currently
  feeds Recently Played and /spotify/info.
• The display push already exists for ICY radio, along with the debounce, the
  Artist / Title / Both mode selector, and the confirmation dialog (title of current song of live internet radio streams #174).
• As far as I can tell this is connecting two ends that are both already built,
  rather than new machinery.

Tradeoff understood: I realise pushing new DIDL means re-issuing
SetAVTransportURI and a re-buffer gap on every track change, and that on a
playlist that's every few minutes rather than every few songs on a radio
station. I'd expect this to ship exactly as the radio version did — same toggle,
off by default, same warning.

Offer: the re-buffer gap is noted as verified on a Portable. I have a Wave
(lisa) and I'm happy to test and report back how long the gap actually is on
this chassis, whether or not the Spotify wiring happens — that data point seems
useful either way.

Thanks for STR. It brought six preset buttons back on a Wave that had been
dead since the shutdown.

[JRpersonal]

Your reading of the code is spot on, both ends exist, and the Wave offer is the missing piece. There is one wrinkle that decides whether it is worth wiring, and it is why I have not done it already.

Radio has two ways onto the display. When the box asks for ICY metadata it de-interleaves the title itself, with no re-fetch and no gap; the SetAVTransportURI re-issue is only the fallback. Spotify is an Ogg passthrough from the engine with no inline metadata, so the re-issue is the only path there. And on Spotify that re-issue is not just a re-buffer, it makes the box drop and re-attach to the Ogg stream, and a re-attach hands the box the cached granule-0 headers again, which is the known cause of a track appearing to restart. So the real risk is not a gap every few minutes but the current song jumping back to its start every few minutes, which is worse than no title.

That is what your Wave measurement would settle, so yes please. Turn the radio display push on, play a Spotify preset, and tell me how long the box goes silent on a title change and whether the track resumes where it was or starts over. If it resumes cleanly on lisa this is the small change you describe and I will build it. If it restarts there is a second piece first, marking the re-attach deliberate and holding the stream position, and your data tells me which.

On the list either way (#390), and thank you, the report, the code-reading and the Wave together are the most useful kind of feature request I get.

[sskubic-eng]

Ran it. Toggle on, mode Both, Spotify preset 5 (Teddy Swims Radio) from theIR remote, let it play through two full track changes.Result: the display never changed. It stayed on the preset name the wholetime, through both track boundaries. No audio interruption at all — not agap, not a stutter, nothing.So on lisa the push isn't firing for Spotify presets at all, which matchesyour reading that the Ogg path has no wiring to the display. Which also meansI couldn't measure the thing you actually need: no re-issue happened, so nore-attach, so nothing to time and no restart to observe. That test needs thewiring to exist first.Two things I did find that may bear on the design.1. The Wave's display truncates hard and does not scroll. "Teddy Swims Radio"rendered as "Teddy Swims Ra" — 14 characters, full stop. So on lisa an"Artist - Title" string would almost never fit, and even Title-only would becut for most songs. Worth knowing before deciding the feature is worth thetradeoff here.2. Watching Spotify on my phone against the speaker, the speaker's audio runsabout 15-20 seconds BEHIND the app. The box is holding a large buffer ahead ofplayback. If a re-issue makes it drop and re-attach, it has to refill all ofthat — which suggests the interruption on lisa could be considerably worsethan the ~1s you measured on a Portable, and possibly a problem in its ownright, separate from the granule-0 restart.Happy to run the same test the moment there's a build or a flag that pushesthe title on the Spotify path — I'll report silence duration and whether thetrack resumes or restarts. Hardware's set up and I can test on demand.Sent from my iPhoneOn Aug 26, 2026, at 10:00 PM, Jens Roggenfelder ***@***.***> wrote:Your reading of the code is spot on, both ends exist, and the Wave offer is the missing piece. There is one wrinkle that decides whether it is worth wiring, and it is why I have not done it already. Radio has two ways onto the display. When the box asks for ICY metadata it de-interleaves the title itself, with no re-fetch and no gap; the SetAVTransportURI re-issue is only the fallback. Spotify is an Ogg passthrough from the engine with no inline metadata, so the re-issue is the only path there. And on Spotify that re-issue is not just a re-buffer, it makes the box drop and re-attach to the Ogg stream, and a re-attach hands the box the cached granule-0 headers again, which is the known cause of a track appearing to restart. So the real risk is not a gap every few minutes but the current song jumping back to its start every few minutes, which is worse than no title. That is what your Wave measurement would settle, so yes please. Turn the radio display push on, play a Spotify preset, and tell me how long the box goes silent on a title change and whether the track resumes where it was or starts over. If it resumes cleanly on lisa this is the small change you describe and I will build it. If it restarts there is a second piece first, marking the re-attach deliberate and holding the stream position, and your data tells me which. On the list either way (#390), and thank you, the report, the code-reading and the Wave together are the most useful kind of feature request I get. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.

[JRpersonal]

That is the answer, and it is cleaner than I feared. The display staying on the preset name means the push is not firing for Spotify at all, rather than firing and restarting the track. The radio display path only triggers on an ICY title, and a Spotify Ogg stream carries none, so nothing reaches the display today. So it is two pieces of work rather than one. Wire the per-track callback into the display push, and hold the stream position across the re-attach so the song does not jump back. Your measurement rules out the worst case, a restart every few minutes, as an inherent problem, which is the good news. On the list (#390); thank you for running it end to end on the Wave.

[JRpersonal]

Shipped in v1.0.13 on every SoundTouch with a display, the Wave included: switch on "Show the current track on the speaker display" in the speaker's settings in the app, and the Spotify track shows on the display while STR's Spotify plays. Screenshots are in #1305. Tell me how it works on your Wave.