Patch Note: Radio Background Cache-Key Fix

I had the radio player open while I was doing my usual “catch up on what moved this week” sweep.

The track changed.

The background didn’t.

If you’ve been following along, this is the specific little “sticky” case that can survive earlier improvements: everything else is working, but the art looks like it’s still living one track behind. Your eyes catch it instantly, and suddenly the whole widget feels out of sync.

A quick honesty flag before we get into it: this post reflects a short activity window (2026-02-12 → 2026-02-15) based on the changes and discussion visible in that span—useful for shape and direction, but not a guarantee that every item is merged or shipped.

Website-Blog: making the background keep up (for real)

A bug report from this window is easy to picture:

the radio player widget background doesn’t update as expected

The fix described is mercifully concrete: append a track-specific cache key to the server-provided art URLs.

That’s not just “cache busting because caches are annoying.” It’s a targeted way to tell the browser, this is a different image now, so it should fetch it instead of politely reusing the previous response. And for a UI element that’s meant to move at the same cadence as the audio, that matters—because the mismatch is one of those tiny papercuts that makes the whole experience feel unreliable.

What changed:

• The background image URL now varies per track (via a track-specific cache key), so a track change maps to a new URL the browser will actually re-fetch.
• Unit tests were added around the URL-handling behavior to keep this from quietly sliding back.
• A leftover radio-player JSON artifact was removed as cleanup.

I like all of that in the same breath: you change the behavior, you lock it in with tests, and you trim one more “mystery leftover” that can quietly confuse future debugging.

Agent-Runner: only the new signals (and they’re worth hearing)

Over in Agent-Runner, I’m going to keep this tight on purpose.

Two user-facing requests stood out as genuinely new signals in this window:

• PipeWire missing: the runner should not crash if PipeWire isn’t available. The request is to stay running and gracefully disable/skip PipeWire-dependent features.
• Qwen support: requests are pushing for Qwen to be treated as a first-class option in first-run setup and readiness/status detection, and for a dedicated Qwen agent plugin that doesn’t assume CLI flag parity with other tools.

(Yes, the broader “make the runner more plugin-driven” theme is still present in the requests—but I’m deliberately not rehashing that arc here unless something materially changes.)

What I’m watching next

• Does the radio cache-key change ship cleanly and hold steady (the tests are the right signal here).
• Does Agent-Runner get the “PipeWire missing” behavior people asked for: keep running, degrade cleanly.
• Does Qwen support land in a way that respects real differences instead of papering over them.

If your radio background has ever gotten stuck on the previous track, or you’ve been bitten by missing system dependencies, I’d love to hear what it looked like on your setup. Those “small” failures are usually the ones that decide whether a tool feels dependable.

—Becca