BBC Radio 1 Stream

[bruceyv83]

This is an awesome project, and i'm up and running quickly.

The problem I'm now trying to solve is the BBC Radio 1 stream in the UK. The BBC don't allow TuneIn to stream BBC content while in the UK, and the only streams I can find online are HLS which I understand are not compatible with Bose. So I created locally hosted converter that takes a HLS stream and converts it to an mp3 stream on my LAN. But when I try to validate the stream in SixBack I get the error: ✗ blocked: host 192.168.1.20 resolves to non-global address 192.168.1.20
Is there another way to achieve streaming Radio 1?

[tostmann]

You've actually got the right approach — the Bose firmware can't decode HLS (.m3u8), so converting it to an MP3 stream on your LAN is exactly the way to get BBC Radio 1 onto the speaker. The only thing in your way is the "Add stream" validation step.

Current status: when you add a custom stream, SixBack validates the URL through a hosted validator, and that validator (a) refuses private/LAN addresses on purpose as a safety measure, and (b) couldn't reach a device on your home network anyway. So right now the UI has no way to accept a LAN stream — even though your speaker, which is on the same LAN, would play it without any problem.

What's coming: I'm going to add an "add anyway / local stream" option over the next few days that skips the hosted validation and stores the URL straight on the device. The speaker fetches the stream directly, so a LAN/self-hosted URL like your transcoder will just work. (I'll keep a light format check so HLS .m3u8 URLs are still flagged, since the speaker can't decode those.)

If you want it working today, there's a manual path — the device's own API isn't gated by that validator, so you can add the stream directly to it:

curl -X POST http://<your-sixback-ip>/api/streams \
  -H 'Content-Type: application/json' \
  -d '{"name":"BBC Radio 1","stream_url":"http://192.168.1.20:PORT/your-stream.mp3"}'

It'll then appear as a tile in the Stream tab, and you can drag it onto a preset like any other station. I'll post back here once the in-UI option ships.

[bruceyv83]

That's awesome, and glad to hear I was on the right track.
Just an fyi, the left hand frame (where you select the stream etc) doesn't scroll. So on my laptop I can't get to the buttons at the bottom. The main frame scrolls fine.

[tostmann]

Thanks for the heads-up — good catch, that's a real bug.

The left media rail wasn't scrolling on shorter (laptop) viewports: the panel was height-capped with no scroll of its own, so when you opened the "add a stream by URL" form the controls at the bottom (+ Add & validate, Export/Import) got clipped off-screen. The main content area has its own scroll, which is exactly why only the left rail felt stuck.

Fixed now — the rail panel scrolls whenever its content doesn't fit, so the bottom buttons stay reachable (the Spotify connect panel had the same root cause and is covered by the same fix). It'll land in the next release; you'll get it over OTA, or you can re-flash.

And the "add anyway / local stream" option for your LAN transcoder is still on the way as promised — I'll post back here once it ships.

[tostmann]

Quick update: v0.8.13 is out and includes the sidebar scroll fix — the left media rail now scrolls on laptop-height viewports, so the buttons at the bottom of the Stream tab are reachable again. Update via System → Check for update (or it arrives with the periodic check).

The "add anyway" option for LAN-only stream URLs is still on the list — that one comes separately.

[bruceyv83]

The scroll bar works, thanks for the fix.

I tried your manual method for adding a local stream, it worked but... I set preset 1 to my local stream and it works. If i turn the speaker off and back on again to preset 1 it still works. But the moment i change to a different preset and then try and go back to preset 1 it stops working. Speaker just has a flashing white led, and I can see the speaker trying to access the Icecast stream.

The only way to recover was to set preset 1 to another station, then, set it back to my radio 1 stream and it works again until I change preset.

I'm not sure where the problem is, my streaming maybe?
Don't waste any effort trying to fix the manual add, I'm happy to wait for the UI integration. But I wanted to let you know just in case it helps.

[tostmann]

@bruceyv83 — this shipped. v0.8.19 adds the "Add anyway" path for exactly your LAN-transcoder case.

What changed: when the hosted online check can't reach your URL or rejects it as a private/LAN address (the non-global address error you hit), an Add anyway button now appears right next to that error. It skips the hosted validation and stores the URL straight on the device. Your speaker is on the same LAN as the transcoder, so it fetches the stream directly — no validator in the path. A self-hosted converter URL just works now.

One guardrail stays: there's still a light client-side format check that hard-blocks HLS (.m3u8) on this path too, because the Bose firmware has no HLS decoder. So your HLS → MP3 transcoder approach is still exactly right — point SixBack at the MP3 output of your converter, not at the upstream .m3u8, and hit Add anyway.

To get it: System → Check for update (OTA), or the web flasher's Update existing button — both keep your WiFi and presets.

Tested end-to-end on a SoundTouch 10 with a LAN-only MP3 URL. Let me know how BBC Radio 1 plays once you're on it.

[bruceyv83]

Yeah, the add anyway works, thanks for adding. However, I still have a problem that if I change away from from Radio 1 preset to another preset then the Radio 1 preset no longer works. The only to get it working again is the map the preset to something else then map it back to my local stream.

[tostmann]

Thanks for the detailed report, and good to hear the "Add anyway" path is working for your LAN/Icecast presets.

I can partly reproduce this. On my test speaker, a cold first select of a custom LAN radio preset connects but never starts playback (flashing white LED, no audio) — exactly your symptom. Re-arming via SixBack (push/play) reliably kicks it off. What I could not reproduce is the persistent failure: once it has played once, re-selecting after switching presets and back stayed reliable across preset switches, AUX, and standby. So the "fails every switch" part did not show up here.

To narrow it down:

• Your speaker model + firmware version.
• Does your transcoder/Icecast cap concurrent listeners or hold the old connection open? The speaker can be slow to drop the previous TCP socket on switch, so a listener-limited source may refuse the re-connect — exactly the white-LED state.
• Point the same preset at a plain, always-on MP3 URL (not the transcoder). That isolates source vs. speaker.

[tostmann]

One shortcut for the first two questions: in Settings, turn on Share diagnostic snapshots (off by default), then hit the 📋 Snapshot button for that speaker. It uploads your speaker model, firmware and live source/preset state to me, so I can check it without the back-and-forth. The plain-MP3 isolation test is still the useful one for the every-switch behaviour.

[tostmann]

Thanks for the snapshot, and especially the SomaFM test — that's the decisive bit: your stream isn't the problem. A public, always-on station with plenty of listener headroom fails exactly the same way as your LAN transcoder, so your converter, your Icecast and the listener count are all ruled out. (The lingering old connections are real — the speaker is slow to drop the previous socket on a switch — but with a 100-listener cap that's not what blocks the reconnect.)

The snapshot shows a SoundTouch 10 on firmware 27.0.6, with Radio 1 as a custom internet-radio preset and 2–6 as TuneIn. That split is the tell: TuneIn is a Bose-native cloud source the speaker keeps "warm", while a custom internet-radio preset goes cold once you switch away — and the next plain hardware-button press then connects but never hands the stream to the playback engine (your flashing-white-LED state). Re-mapping recovers it because it forces a fresh push that re-arms the source.

The awkward truth: the Bose firmware sends no event when you press a physical preset button. SixBack drives everything over the network, but a hardware press is invisible to it, so it can't re-arm the cold source for you. That's a hard limit of the frozen firmware, not something I can patch.

I can reproduce the cold first-select failure on the bench, but not the "fails on every switch" persistence — my test unit runs a slightly older 27.0.x release than your 27.0.6, so a firmware-version difference is my leading suspect.

For now the dependable trigger is to start the preset from the SixBack web UI (click/play the slot) rather than the hardware button — that re-arms and plays every time. Not the physical-button experience you want, I know. I'm looking at keeping a custom-radio source warm in the background so the button survives a switch; the catch is any keep-alive risks a brief interruption, so I want it right rather than stuttering. It's on the list, and your report moved it up.

One quick check if you don't mind: after switching away and back, does triggering Radio 1 from the app play reliably while only the hardware button fails? If so, that pins it exactly and tells me where to aim. Thanks again — textbook bug report.

[bruceyv83]

So my setup also fails while pressing the presets in Sixback web UI, most of my testing has been using that rather than the physical buttons.
By app do you mean the old Soundtouch app? I dont seem to have the ability to select presets on it anymore.

Interesting how TuneIn stations are handled differently.

[tostmann]

Quick clarification first: by "app" I meant the SixBack web UI, not the old SoundTouch app — and you're right, that one can't select presets anymore since the shutdown, so ignore that part.

More important, you've corrected me — thanks. I checked: SixBack's preset play button currently just emulates a physical button press, so it goes down the exact same cold-select path and fails identically. My "reliable via the web UI" was wrong.

The useful bit is why re-assigning the stream to the slot recovers it: that action takes a different path that re-resolves the stream before playing — the same way the Bose-native sources like TuneIn are resolved on every play, which is exactly why TuneIn never goes cold and a static custom URL does. And that re-resolve path is fully under SixBack's control, unlike the physical button. So I can make the web-UI play button re-resolve custom-radio presets the same way, which should make playing from the UI reliable. The physical button stays limited (SixBack can't see the press), but the UI shouldn't be. I'll try it and report back.

[tostmann]

Reported back as promised: this shipped in v0.8.20.

What changed: clicking a Custom Stations (custom internet-radio) preset in the SixBack web UI now re-resolves the stream before playing, instead of just emulating a preset-key press. That's the path that reliably engages the speaker's playback engine, so a custom-radio preset plays from cold — including after you've switched to another preset and back. In other words, the exact thing that was failing for you from the UI now works.

I verified it on a SoundTouch 10: from a cold source, the old button-press path left it stuck (the speaker connects but the playback engine never starts — your flashing-white-LED state), while the new path starts playback every time. Both your LAN transcoder and a plain public stream came up cleanly.

One honest caveat I want to keep straight: this fixes the web-UI play (and push/preview). The physical preset button on the speaker still has the underlying limitation — the Bose firmware sends no event when it's pressed, so SixBack can't re-arm the source for it. For custom radio, trigger it from the web UI and it'll be reliable.

To get it: System → Check for update (OTA), or the web flasher's Update existing button — both keep your WiFi and presets. Give it a try and let me know how BBC Radio 1 behaves now.

[bruceyv83]

Much better switching between presets via the Sixback UI now. I'll be keeping an eye to see if you manage to solve the physical buttons problem

[tostmann]

@bruceyv83 — follow-up on the physical-buttons question you raised here.

v0.8.23 adds hardware preset-button re-arm for cold Internet-Radio slots. When you press a preset button (1–6) on the speaker itself and that slot is a Local-Internet-Radio station that wouldn't start from a cold/idle speaker, SixBack now notices the press in real time over the speaker's gabbo notification socket and re-arms the station through the same native path the WebUI Play button uses (the v0.8.20 fix) — so the physical button just plays the station again, no app involved.

Two caveats worth knowing:

• It's enabled on the ESP32-S3 / S3-8MB builds only. It keeps a small WebSocket connection open per speaker and needs the PSRAM headroom, so on C3 / C6 / ESP32-classic it's compiled out. If you're on an S3 you're all set; if not, let me know your board.
• It targets Local-Internet-Radio preset slots — the cold-start case you hit. TuneIn slots already worked.

Update to v0.8.23 (OTA from the WebUI, or re-flash from https://sixback.io/) and give the physical buttons a try. Verified end-to-end on test hardware here — but I'd really like to hear whether it sorts it on your setup.

[michelk67]

Hello,
First of all, thank you for your work, which has allowed me to bring my Bose SoundTouch speakers back to life.
I’m having the same issue as bruceyv83.
I’ve saved presets on my SoundTouch 10 & 20.
Five of the presets come directly from ‘TuneIn’, but my favourite radio station isn’t available via TuneIn, so I’ve added the URL
http://direct.francebleu.fr/live/fbalsace-midfi.mp3

If I control the presets via the Sixback web interface, I don’t encounter any problems.
If I use the radio’s presets (physical buttons or remote control), I can’t switch between TuneIn and MP3 mode.

As the radio is at my elderly parents’ house, it’s difficult to ask them to use a smartphone or computer to change stations!
I hope a solution can be found to this problem.
I’m using sixback version 0.8.22

[betateilchen]

@michelk67 is it the same radio station as https://icecast.radiofrance.fr/fbalsace-midfi.mp3?
Working on my ST20 together with 5 TuneIn stations without any problem.

[tostmann]

@michelk67 — thanks, and you've described exactly the same cold-source issue bruceyv83 hit earlier in this thread. The good news: the fix for the physical preset buttons shipped today in v0.8.23, and you're on v0.8.22 — so you don't have it yet.

What's actually going on:

• TuneIn presets are a Bose-native cloud source, so the firmware keeps them "warm" and the hardware button just works.
• A custom Local-Internet-Radio preset (your France Bleu MP3) goes cold once you switch away. The next plain hardware-button press connects but never hands the stream to the playback engine — so nothing plays. That's exactly why the web UI works (it re-resolves the stream before playing) while the physical button doesn't.
• v0.8.20 fixed the web-UI play button for this. v0.8.23 now also re-arms the source on a physical button press: it watches the speaker's notification socket and re-resolves the cold station the moment you press the button.

One important catch: the hardware-button re-arm is enabled on the ESP32-S3 / S3-8MB SixBack builds only — it keeps a small connection open per speaker and needs the PSRAM headroom, so it's compiled out on C3 / C6 / ESP32-classic sticks. So the question that decides whether v0.8.23 fixes this for you: which ESP32 board is your SixBack stick? (The SoundTouch 10/20 model doesn't matter here — this is about the stick, not the speaker.) If it's an S3, update to v0.8.23 (System → Check for update, OTA keeps your WiFi and presets) and the physical buttons should re-arm France Bleu for you. If it's a C3/C6, the reliable path today is still the web UI — which I realise doesn't help much with the speaker at your parents' place. Tell me your board and I'll see what's feasible there.

On the remote control: the fix keys off the speaker's preset-press notification. I've verified the top-panel buttons; the IR remote should take the same path, but I haven't confirmed that specifically — if you end up on an S3 with v0.8.23, I'd be glad to hear whether the remote re-arms too.

@betateilchen — thanks for jumping in. icecast.radiofrance.fr/fbalsace-midfi.mp3 is the canonical Radio France endpoint for the same station as @michelk67's direct.francebleu.fr URL, so either works — that difference isn't the cause here, the cold-source behaviour is. Good to know the buttons are reliable on your ST20.

[bruceyv83]

Oh this is working really well now. Thanks for the hard work.... happy wife... happy life!

[michelk67]

Thank you very much for all your hard work and for your prompt response.
Everything is working properly now. :-)

[tostmann]

@michelk67 — thanks, and you've described it exactly: the WebUI plays your France Bleu MP3 preset fine, but pressing the physical preset button (or the remote) for it from a cold/idle speaker doesn't start it. That's the known cold-start behaviour for Local-Internet-Radio presets, and there's a fix — but whether it reaches you depends on one thing I need to check first.

The hardware-button fix needs an ESP32-S3. The physical-button re-arm (added in v0.8.23) keeps a small notification socket open to each speaker so it can catch the button press and re-start the station the same way the WebUI Play button does. That needs the PSRAM headroom of the S3, so on the C3 / C6 / ESP32-classic builds it's compiled out. The WebUI Play path — the one that works for you — isn't gated like that, which is exactly why you see the split between the app and the physical buttons.

So: which ESP32 board is your SixBack stick? This is the ESP32 itself, not the speaker — your ST10 and ST20 are both fine either way. You can see it in the WebUI under System, or it's whichever firmware you flashed from the web installer (s3 / s3-8mb / c3 / c6 / esp32).

• If it's an S3 (or S3-8MB): you're on v0.8.22, and this shipped in v0.8.23. Update to the current release (v0.8.25) via System → Check for update — it's an OTA, no reflash and no trip to your parents' place needed beyond being on their network once. After that, pressing the physical button for the France Bleu preset should start the station from a cold speaker. (Verified end-to-end on test hardware here — I'd like to hear whether it sorts it on your setup.)
• If it's a C3 / C6 / ESP32-classic: the physical-button re-arm isn't available on that board yet, for the memory reason above. Updating still gets you every other fix, but the hardware button for the MP3 preset specifically won't be covered. If that's your case, let me know — for a buttons-only setup like your parents', the S3 (or S3-8MB) is the board that has this working today.

(@betateilchen — good question. The specific URL isn't what causes the cold-button behaviour — that's about the source type, Local-Internet-Radio vs TuneIn, and the press from idle. But it's still worth pinning down: a listener-capped or flaky endpoint can independently cause a connection that never starts (flashing white LED, no audio), so pointing the preset at a stable, always-on MP3 endpoint like the radiofrance icecast one is the right move regardless.)

Let me know the board and we'll take it from there.

[michelk67]

@tostmann

The ESP used for SixBack is an S3 N16R8.

I updated it to version 0.8.25.
I also took the opportunity to correct the radio stream URL by using the URL you provided.

After the update, I had to resynchronize the radio stations with the SixBack server.
The "memory" buttons work correctly, although the switchover time can take a few seconds (the time it takes for the SixBack server to pool the radio station and then tell it to change sources).

Everything works correctly for my parents' needs.
Thank's for your work and quick response to the problem.

[tostmann]

Great to hear, @michelk67 — and that wraps up this thread nicely.

The physical preset buttons switching reliably between TuneIn presets and a custom MP3 stream (your France Bleu, @bruceyv83's BBC Radio 1) is exactly what the v0.8.23 hardware-button re-arm was for — now confirmed on real S3 setups on both your sides.

On the few-seconds switchover you noticed: that's expected, not a fault. For a custom internet-radio preset, SixBack re-resolves the stream and hands it to the speaker on each press, whereas TuneIn presets are kept warm by the firmware and come up a touch quicker. A short, reliable delay beats the old flashing-white-LED dead end.

I'll close this as resolved. Thanks both for the detailed back-and-forth and for circling back with the results — that's exactly what pinned down the cold-source behaviour and the S3-only constraint of the fix. If it ever regresses, reopen this one or file a fresh report.

Enjoy the radio. 📻