Show the current title on the speaker display without the ~1 s audio gap (like the old Bose cloud)

[meierchen006]

Hallo Jens @JRpersonal ,

eine Idee zur Einstellung „Aktuellen Titel am Lautsprecher-Display anzeigen". Die Funktion
ist super — nur der Hinweis „setzt bei jeder Titeländerung ~1 s aus" hält mich (und
vermutlich andere) vom Aktivieren ab. Ich glaube, das ließe sich lückenlos lösen, und wollte
den Gedanken teilen.

Wie ich das Verhalten verstehe: Das Box-Display bezieht den Titel aus den
UPnP-Transport-Metadaten. Um den Text zu ändern, wird der Stream neu angestoßen → die Box
puffert neu → der ~1-s-Aussetzer. In meinem agent.log sehe ich außerdem bei jeder Station
stream proxy ICY negotiation boxWantsICY=false — die Box liest den Titel also nicht
inband aus dem Stream (ICY-Metadaten wären der lückenlose Weg, aber die Firmware lehnt sie ab).
Deshalb bleibt aktuell nur der Transport-Umweg mit Neupufferung.

Der springende Punkt: Die alte Bose-Cloud hat den Radiotitel bei TuneIn ohne
Aussetzer aufs Display gebracht — nicht über den Transport, sondern als „now playing"-
Benachrichtigung über den Bose-eigenen Push-Kanal (gabbo-WebSocket :8080 / marge), getrennt
vom Audio. Die Box aktualisierte nur die Anzeige, der Ton lief lückenlos weiter.

Die Idee: STR kennt den Live-Titel ja bereits — es liest ihn aus den ICY-Metadaten des
Streams und zeigt ihn in der App/WebUI ohne Unterbrechung an (stream proxy ICY title … im
Log). Es fehlt nur der letzte Schritt: diesen Titel über denselben gabbo/marge-nowPlaying-
Notification-Weg ans Box-Display schicken, wie es die Cloud tat — statt über einen
Transport-Re-Push. Ergebnis wäre: Titel am Display und lückenloser Ton, wie früher beim
Internetradio.

Mir ist klar, dass das an der Marge-Emulation hängt und nicht trivial ist — aber da STR den
Titel schon hat und den gabbo/marge-Kanal ohnehin bedient, schien mir der Weg zumindest
plausibel. Zum Testen stelle ich meine ST20 gern zur Verfügung (Radio mit häufigen
Titelwechseln lässt sich leicht reproduzieren).

Viele Grüße

[JRpersonal]

User proposes sending the live ICY title to the speaker display over the gabbo/marge nowPlaying push channel instead of re-pushing the UPnP transport, which would avoid the ~1 s audio gap. He offers his ST20 for testing.

Hi @meierchen006,

your analysis is right in every step but the last one, and I can save you the experiment: I tried exactly that on hardware on 5 July, on a Portable.

A second gabbo client sent a <updates><nowPlayingUpdated> frame to the speaker while it was playing radio. The box rejected it with "msg expected, but XML was 'updates'". Probing further showed why: gabbo is a request and response API, clients send <msg> with a header, and <updates> frames only ever travel from the box to the client. There is no client writable now playing.

The reason the old cloud managed it is not that it had a special channel: with native TuneIn the speaker's own source was playing the stream, so it owned the now playing text and updated its display internally. Nothing was injected from outside. STR is outside, and the only route from outside is the transport, which re-buffers.

Your ICY observation is the other half of the same wall: boxWantsICY=false means the firmware declines to read the title inband, which would have been the gap-free path.

So the display stays opt-in with the short interruption, and I am closing #199, which tracked this idea, with the same finding so nobody spends another evening on it. Thanks for the offer of the ST20 and for thinking it through this far.

Hi @meierchen006,

deine Analyse stimmt bis auf den letzten Schritt, und den Versuch kann ich dir ersparen: Ich habe genau das am 5. Juli an echter Hardware getestet, an einer Portable.

Ein zweiter gabbo-Client hat der Box im laufenden Radiobetrieb einen <updates><nowPlayingUpdated>-Frame geschickt. Die Box hat ihn abgelehnt, mit "msg expected, but XML was 'updates'". Die Nachfrage hat gezeigt, warum: gabbo ist eine Anfrage/Antwort-Schnittstelle, Clients senden <msg> mit Header, und <updates> laufen ausschließlich von der Box zum Client. Ein von außen beschreibbares "now playing" gibt es nicht.

Dass die alte Cloud das konnte, lag nicht an einem besonderen Kanal: Bei nativem TuneIn hat die Box den Stream selbst abgespielt, also gehörte ihr der Titel und sie hat ihr Display intern aktualisiert. Von außen wurde nichts eingespielt. STR ist außen, und von außen führt nur der Transportweg hin, und der puffert neu.

Deine ICY-Beobachtung ist die andere Hälfte derselben Wand: boxWantsICY=false heißt, die Firmware liest den Titel nicht inband, das wäre der lückenlose Weg gewesen.

Die Anzeige bleibt also optional mit der kurzen Unterbrechung, und ich schließe #199, wo diese Idee lief, mit demselben Ergebnis, damit niemand noch einen Abend darauf verwendet. Danke für das Angebot mit der ST20 und dafür, dass du das so weit durchdacht hast.

[meierchen006]

Hallo Jens @JRpersonal

Danke für die ausführliche Antwort — und dafür, dass du den gabbo-Weg extra an echter Hardware
getestet hast. Dass die Box <updates><nowPlayingUpdated> mit „msg expected…" ablehnt und
gabbo nur Box→Client funktioniert, leuchtet ein.

Ein Gedanke noch, der genau an deiner eigenen Erklärung ansetzt — du schriebst ja: „die Box
konnte das Display lückenlos steuern, weil sie den TuneIn-Stream selbst abgespielt hat". Das
Entscheidende ist also nicht der Push-Kanal, sondern wer den Stream abspielt. Aktuell
liefert STR über UPnP (die Box ist nur Fernabspieler → Display-Änderung = Transport neu =
Neupufferung). Die Box hat aber eine native Radio-Quelle: LOCAL_INTERNET_RADIO.

Die Idee: Sender über LOCAL_INTERNET_RADIO ausliefern statt über UPnP → die Box spielt
selbst und steuert ihr Display intern (wie bei TuneIn). Den Titel würde die Box dann nicht
aus dem Transport ziehen, sondern — wie damals bei der Cloud — über einen separaten
„now playing"-Metadaten-Abruf, während der Ton durchläuft. STR müsste diesen
Metadaten-Feed emulieren (den Titel hat STR aus den ICY-Daten ja bereits). Ergebnis:
Titel am Display und lückenloser Ton.

Was ich dazu selbst geprüft habe (damit's nicht naiv rüberkommt): Auf meiner ST20 ist
LOCAL_INTERNET_RADIO inzwischen komplett aus /sources verschwunden (früher war es
READY), genau wie TUNEIN. Die Box bietet die native Radio-Quelle also nur an, solange sie
deren Backend (vtuner/Cloud) erreicht — und das ist tot. Ich sehe also, dass dieser Weg
deutlich mehr Aufwand bedeutet als der UPnP-Proxy: STR müsste die Quelle erst wieder
verfügbar machen (Backend emulieren: Senderliste + now-playing-Feed), nicht nur „eine andere
Quelle wählen". Mir ist klar, dass das ein Grund sein kann, warum du bewusst UPnP nutzt.

Deshalb keine Forderung, sondern eine ehrliche Frage: Hast du den nativen
LOCAL_INTERNET_RADIO-Weg mal angeschaut — und wenn ja, woran scheitert er? (Liest die Box
bei dieser Quelle den Titel inband/ICY, oder erwartet sie zwingend einen Bose-Metadaten-Dienst,
den man nicht sinnvoll nachbauen kann?) Falls das eine Sackgasse ist, wüsste ich's gern
endgültig — und falls nicht, wäre es vielleicht der eine Weg zum lückenlosen Display. Zum
Testen stelle ich meine ST20 gern zur Verfügung.

Viele Grüße

[JRpersonal]

Hi @meierchen006,

(English summary: about serving radio through the box's native LOCAL_INTERNET_RADIO source with an emulated backend. Answer: yes, that is the planned durable path; the open question is the metadata mechanism, and help with pre-shutdown captures or protocol knowledge is very welcome.)

In English: I have looked at this path, and it is the direction I want to take for the durable fix, not just for the display. The source drops out of /sources because the firmware only advertises it while its backend answers, so STR's local cloud emulation would have to stand in for that backend too: station list plus the now-playing feed. Whether the box then reads titles inband from ICY or insists on the emulated metadata service is the open question only a hardware test settles. This is the next larger project after the current stability work.

And this is a genuinely good spot for community help. If anyone still has pre-shutdown network captures of LOCAL_INTERNET_RADIO or vtuner traffic (station list XML, the now-playing/metadata requests), knows the request shapes from other vtuner-based radios, or can lend test time on their own hardware: please post here, every capture shortens the reverse engineering considerably.

Auf Deutsch: ja, diesen Weg habe ich auf dem Zettel, und zwar als Dauerlösung, nicht nur fürs Display. Die Quelle verschwindet aus /sources, weil die Firmware sie nur anbietet, solange ihr Backend antwortet. STR emuliert die Bose-Cloud ja bereits lokal, also ist der Plan, auch dieses Backend nachzubilden: Senderliste plus now-playing-Feed. Ob die Box den Titel dann inband aus ICY liest oder zwingend den Metadaten-Dienst erwartet, entscheidet nur ein Test an echter Hardware. Es ist das nächste größere Projekt nach der aktuellen Stabilitätsarbeit, versprechen kann ich noch nichts.

Und genau hier kann die Community richtig helfen: Falls noch jemand Netzwerk-Mitschnitte von LOCAL_INTERNET_RADIO oder vtuner aus der Zeit vor der Abschaltung hat (Senderlisten-XML, die now-playing-Abrufe), die Request-Formate von anderen vtuner-Radios kennt oder Testzeit auf eigener Hardware beisteuern mag: gern hier in den Thread damit, jeder Mitschnitt spart uns ein gutes Stück Reverse Engineering. Dein ST20-Angebot nehme ich dafür schon mal dankend an, ich melde mich, sobald es einen Testbuild gibt.

Gruß Jens

[meierchen006]

Hallo Jens @JRpersonal

Ich hab auf der ST20 mal einen kleinen Vorab-Test gemacht, um deiner „kritischen Unbekannten"
näherzukommen — Ergebnis grenzt die Sache zumindest ein.

Aufbau: kleiner ICY-Proxy auf dem PC (proxyt einen Plain-HTTP-Stream und spritzt einen
steuerbaren StreamTitle ein, loggt außerdem, ob die Box überhaupt Icy-MetaData: 1
anfragt). Die Box erreicht den PC-Server problemlos (kein Firewall-Thema). Dann per Bose-WebAPI
POST /select eine LOCAL_INTERNET_RADIO-ContentItem draufgegeben
(type="stationurl", location=http://<pc>/station.json).

Ergebnis: Die Box lehnt sofort ab:

POST /select  (source=LOCAL_INTERNET_RADIO)
-> <error value="1005" name="UNKNOWN_SOURCE_ERROR" />
   now_playing: source=INVALID_SOURCE

Mein Server-Log zeigt: Die Box hat die Station-URL nicht einmal abgerufen — es kam kein
einziger Request auf station.json oder /stream. Die Quelle wird also vor jedem
Stream-/Metadaten-Schritt als unbekannt verworfen.

Was das (für mich) bedeutet: LOCAL_INTERNET_RADIO ist nicht bloß „unavailable" in
/sources — der Quell-Typ selbst ist der Firmware ohne lebendes Backend unbekannt.
Man kann ihn also nicht von außen über eine Station-URL wiederbeleben. Die eigentliche
Hürde liegt damit noch vor der ICY-Frage: Zuerst muss das Backend die Quelle überhaupt
wieder „known/READY" machen (der vtuner-/Radio-Service-Handshake) — erst danach ließe
sich testen, ob die Box den Titel inband aus ICY liest oder einen Metadaten-Dienst erwartet.

Falls es hilft: Das grenzt ein, wo alte vtuner-Mitschnitte am wertvollsten wären — nämlich
beim Source-/Registrierungs-Handshake (was macht die Quelle „READY"), nicht erst beim
now-playing-Feed. Ich probiere gern weiter, wenn du eine Idee hast, wie man die Quelle
zum „READY" bringt — dann teste ich die ICY-Frage sofort nach.

Viele Grüße

Nachtrag

mit einem Fund, der die Sache aus meiner Sicht deutlich vereinfacht — ich hab auf
der ST20 nachgesehen, welchen Radio-Dienst die Firmware eigentlich anspricht.

In der von STR verwalteten /etc/hosts steht neben den beiden Bose-Cloud-Domains eine dritte,
umgeleitete Adresse:

127.0.0.1   streaming.bose.com                                   (marge/Konto)
127.0.0.1   content.api.bose.io                                  (bmx)
127.0.0.1   7f5…f4.api.radiotime.com   <-- der Radio-Dienst

radiotime.com ist TuneIn (RadioTime = alter Name von TuneIn). Die SoundTouch nutzt für
Internetradio also nicht vtuner, sondern die TuneIn-API, über eine geräte-spezifische
Hash-Subdomain. Vom PC aus geprüft:

• 7f5…api.radiotime.com (der Bose-Partner-Zugang) → antwortet nicht mehr (weder
  HTTP noch HTTPS) — die Bose-TuneIn-Partnerschaft ist offenbar abgeschaltet, und STR biegt
  die Domain ohnehin auf 127.0.0.1. Das erklärt das 1005 UNKNOWN_SOURCE /
  LOCAL_INTERNET_RADIO-Verschwinden.
• ABER die allgemeine TuneIn-API lebt: http://opml.radiotime.com/Browse.ashx →
  HTTP/1.1 200 OK, Content-Type: text/xml. Plain-HTTP, XML, online.

Warum das die Machbarkeit stark verbessert:

1. Es ist kein unbekanntes vtuner-Protokoll, das reverse-engineert werden müsste — es ist
   die öffentlich dokumentierte TuneIn/RadioTime-OPML-API, die viele Geräte anderer
   Marken nutzen und die weiter online ist.
2. Der „Backend nachbilden"-Schritt wäre damit eher ein Proxy: den toten
   …radiotime.com-Endpunkt der Box abfangen und auf das lebende opml.radiotime.com
   umsetzen (ggf. mit kleiner Bose-spezifischer Anpassung). Alte Mitschnitte braucht man
   dafür vermutlich gar nicht.
3. Und das schließt den Kreis zu dieser Discussion: Sobald LOCAL_INTERNET_RADIO so wieder
   „READY" ist, spielt die Box TuneIn wieder selbst und steuert ihr Display intern —
   also lückenlos, genau wie du es für die alte Cloud beschrieben hast. Der Umweg über
   UPnP (mit der Neupufferung) fiele weg.

Was ich nicht testen konnte: die exakten Requests, die die Box an den TuneIn-Endpunkt
schickt (dafür müsste man die Domain auf einen Log-Server umbiegen — /etc/hosts liegt hier
aber auf einem read-only rootfs, das wollte ich nicht anfassen). Wenn dir die genauen
Box-Requests helfen, mache ich das bei Gelegenheit sauber — sag einfach, was du brauchst.

Kurz: Der Radio-Dienst ist TuneIn, und TuneIns API ist noch da. Das ist hoffentlich ein
brauchbarer Startpunkt.

Leider bin ich die nächsten 4-5 Wochen nicht online und kann nicht weiter helfen!

[JRpersonal]

Hi @meierchen006,

(English summary: their test showed LOCAL_INTERNET_RADIO is rejected as an unknown source before any stream request, and they identified the radio backend as TuneIn/RadioTime. Answer: the registration handshake is now solved, and here is exactly what makes the source READY.)

In English: your analysis is right, and the step you identified as the real hurdle is solved. The source has to be made known through the emulated account before any station URL is touched, which is exactly why your POST /select never produced a single request on your server.

Three things make it READY, and all three are needed:

1. The account data must contain a devices block naming the speaker's own device ID. The firmware discards the entire account when it cannot find itself in it, and that account is what carries the source. This was also a real bug on my side: a speaker reports two hardware addresses and STR was using the wrong one, so the account was thrown away and the source vanished after a restart.
2. The source entry uses the numeric provider id 11 with an empty user name, and the service registry has to be in the firmware's own schema, with an anonymous account that creates itself.
3. The ContentItem location must be relative to the service base URL, not a full URL, and the type is stationurl.

With that in place the speaker activates the station by itself and pulls the stream, roughly 0.65 seconds from pressing a hardware key, with no error and without STR intervening at all. Measured on a SoundTouch 10 and a Portable, and it is in the next release.

Your ICY question is now genuinely testable, and it is the part I cannot answer yet: I can see the speaker fetch the stream, but not whether it reads the title inband or expects a metadata service.

Your radiotime.com find is valuable and I had not followed that thread. It is not needed to make the source READY, but it is very likely the route to browsing stations on the speaker itself.

Enjoy the weeks offline, and thank you, this was a genuinely useful piece of work.

Auf Deutsch: deine Analyse stimmt, und genau die Hürde, die du benannt hast, ist gelöst. Die Quelle muss über das emulierte Konto bekannt gemacht werden, bevor überhaupt eine Station-URL angefasst wird. Deshalb kam bei deinem POST /select kein einziger Request auf deinem Server an.

Drei Dinge machen sie READY, und alle drei sind nötig:

1. Die Kontodaten müssen einen devices-Block enthalten, der die eigene Geräte-ID des Lautsprechers nennt. Die Firmware verwirft das komplette Konto, wenn sie sich darin nicht selbst findet, und dieses Konto trägt die Quelle. Das war bei mir zusätzlich ein echter Fehler: ein Lautsprecher meldet zwei Hardware-Adressen, und STR hat die falsche benutzt. Dadurch wurde das Konto verworfen und die Quelle war nach einem Neustart weg.
2. Der Quelleneintrag nutzt die numerische Provider-ID 11 mit leerem Benutzernamen, und die Dienst-Registry muss im Schema der Firmware selbst kommen, mit einem anonymen Konto, das sich selbst anlegt.
3. Die Location im ContentItem muss relativ zur Basis-URL des Dienstes sein, keine vollständige URL, und der Typ ist stationurl.

Damit aktiviert der Lautsprecher die Station selbst und holt sich den Stream, etwa 0,65 Sekunden nach dem Druck auf eine Hardware-Taste, ohne Fehler und ohne dass STR eingreift. Gemessen auf einer SoundTouch 10 und einer Portable, und es ist im nächsten Release.

Deine ICY-Frage lässt sich jetzt wirklich testen, und genau die kann ich noch nicht beantworten: ich sehe, dass der Lautsprecher den Stream holt, aber nicht, ob er den Titel inband liest oder einen Metadaten-Dienst erwartet.

Dein radiotime.com-Fund ist wertvoll, den Faden hatte ich nicht verfolgt. Für das READY-Machen der Quelle braucht man ihn nicht, aber er ist sehr wahrscheinlich der Weg zum Senderstöbern direkt am Lautsprecher.

Viel Spaß bei der Offline-Zeit, und danke, das war ein richtig nützliches Stück Arbeit.

[meierchen006]

Hallo Jens,

danke für die Arbeit seit August. Die schnelle Radioform (LOCAL_INTERNET_RADIO) läuft bei mir. Ich habe heute auf meiner ST20 (FW 27.0.6, STR v0.9.95) nachgemessen, wie der Titel-Push aufs Display den Ton unterbricht. Dabei habe ich auch einen Ausweg getestet, der leider nicht funktioniert. Hier die Ergebnisse, damit du dir diesen Umweg sparen kannst.

1. Der Aussetzer im Protokoll (Titel am Display = An, Modus „Beides")

Taste 3 (SR3) an der Box gedrückt:

13:40:49.090 hardware preset: native radio preset, the box activates it itself  slot=3
13:40:50.202 stream proxy start  slot=3  ua=Bose/7.22.0  icyReq=""
13:40:50.955 stream proxy ICY negotiation  boxWantsICY=false  upstreamMetaint=16384
13:40:51.092 stream proxy ICY title  title="Sie hören "Die Prinzen" mit "Alles nur geklaut"."
13:40:51.679 display push  boxURL=http://127.0.0.1:8888/stream/3
13:40:52.118 stream proxy end: bose disconnected  elapsed=2s
13:40:52.313 stream proxy start  slot=3

Nächster Titelwechsel, mitten im laufenden Strom:

13:43:47.708 stream proxy ICY title  title=""
13:43:53.836 stream proxy ICY title  title="Sie hören "Lobo" mit "I'd love you to want me"."
13:43:55.778 display push
13:43:56.723 stream proxy end: bose disconnected  elapsed=3m4s
13:43:57.038 stream proxy start  slot=3
13:43:57.819 box syslog: play_underrun  "ReadyToWrite Interrupted, bufferDepth: 385618, capSize: 384000,
             totalSize: 1572864, minBufferDepth: 1.500000"

Bei jedem Titelwechsel trennt die Box also die Verbindung, verwirft ihren Puffer und braucht wieder mindestens 1,5 s Vorlauf. Der Aussetzer ist deutlich hörbar.

Zwei Nebenbefunde:

• Die Box fordert auch auf dem nativen Weg kein ICY an (boxWantsICY=false, icyReq="" schon beim ersten Start über die Taste). Deine offene Frage vom 03.08. („liest die Box den Titel inband?") ist damit zumindest für diesen Weg mit Nein beantwortet.
• SR3 schickt zwischen zwei Titeln kurz einen leeren StreamTitle (13:43:47, 6 s vor dem neuen Titel). Falls der leere Titel auch einen Push auslöst, wären das zwei Aussetzer pro Wechsel. Ein Filter auf leere Titel wäre einfach.

2. Getestet und verworfen: SetNextAVTransportURI

Meine Idee war: Den Radiostrom bei jedem Titelwechsel an einer MP3-Rahmengrenze in „Stücke" schneiden und das nächste Stück mit neuem dc:title per SetNextAVTransportURI vormelden. So würde die Box nahtlos weiterspielen wie bei einem Album, nur mit neuem Titel im Display.

Die Aktion steht zwar in der SCPD der ST20 (/Xml/AVTransport3.xml), aber:

SetAVTransportURI (Stück 1, DIDL mit dc:title "Test A")  -> 200, spielt, Display zeigt "Test A"
SetNextAVTransportURI (Stück 2, mit DIDL)                 -> 500  UPnPError 401 Invalid Action
SetNextAVTransportURI (Stück 2, NextURIMetaData leer)     -> 500  UPnPError 401 Invalid Action

Die Firmware hat die Aktion nicht implementiert. Nach dem Ende von Stück 1 geht die Box auf STOPPED. Zwei weitere Auffälligkeiten aus dem Test:

• GetMediaInfo meldet als CurrentURI immer qplay://. Das tatsächlich laufende Stück steht nur in GetPositionInfo unter TrackURI.
• Nachdem der Testserver weg war, blieb die Box mit PLAY_STATE auf der toten URL stehen. Erst ein Druck auf eine Stationstaste hat sie gelöst.

Das Testskript (Python, rahmengenauer Schnitt plus SOAP-Aufrufe) gebe ich dir gern, falls du es auf anderen Modellen ausprobieren willst. Die ST300 habe ich nicht getestet.

3. Frage: Was ist mit dem TuneIn-Weg?

STR leitet …api.radiotime.com schon auf die Box selbst um. Weißt du, ob die Bose-Firmware beim alten TuneIn-Radio den laufenden Titel selbst bei TuneIn abgefragt hat, also unabhängig vom Audiostrom? Dann könnte STR diese Abfrage beantworten, und die Box würde den Titel ohne Neupufferung anzeigen. Wenn du dazu einen Mitschnitt oder einen Test auf der ST20 brauchst, helfe ich gern.

Bis dahin lasse ich den Schalter auf „Aus". Der Titel in der App und auf der Handy-Fernbedienung reicht mir.

Viele Grüße
Andreas

[JRpersonal]

User reports: measurements of the stream drop on every title push, and a failed SetNextAVTransportURI workaround.

The empty StreamTitle already never triggers a push, your own log agrees (nothing at 13:43:47, the push came at :55 with the new title). So it is one gap per song, not two. What did cost a gap for nothing was a change that leaves the display text the same, for example two songs by the same artist in "Artist only" mode. That push is skipped from the next release on.

The gap itself stays. A fresh SetAVTransportURI is the only way to put a title on the display, and the box treats it as a new play. Your 401 on SetNextAVTransportURI closed the last door I knew of, and I recorded it together with the qplay:// quirk in the firmware notes.

As for TuneIn, the old client in the firmware knew a nowPlaying route on the radiotime partner host, so it very likely fetched the title itself. On 27.0.6 that client never starts, and I have never seen a box contact that host, even though STR points it at the speaker. The test that settles it is to register TUNEIN in the emulated account, play a TuneIn station and watch whether a request arrives. If you want to run that on your ST20, I would take you up on it and send you the steps.

Switch off is the right setting until then.

Auf Deutsch: Ein leerer StreamTitle löst schon heute keinen Push aus, dein Log zeigt das auch (um 13:43:47 nichts, der Push kam um :55 mit dem neuen Titel). Es bleibt also bei einem Aussetzer pro Song. Unnötig war dagegen ein Push, der den Displaytext gar nicht ändert, etwa zwei Songs vom selben Interpreten im Modus „Nur Interpret". Den lasse ich ab dem nächsten Release weg.

Der Aussetzer selbst bleibt. Ein neues SetAVTransportURI ist der einzige Weg, einen Titel aufs Display zu bringen, und die Box behandelt das als neue Wiedergabe. Dein 401 auf SetNextAVTransportURI hat die letzte Tür zugemacht, die ich kannte. Das Ergebnis und die qplay://-Eigenheit stehen jetzt in den Firmware-Notizen.

Der alte TuneIn-Client der Firmware kannte eine nowPlaying-Route auf dem radiotime-Partnerhost, hat den Titel also sehr wahrscheinlich selbst abgefragt. Auf 27.0.6 startet dieser Client aber nie, und ich habe noch keine Box gesehen, die den Host anspricht, obwohl STR ihn auf den Lautsprecher umleitet. Klären würde es ein Test, bei dem TUNEIN im emulierten Konto registriert wird, ein TuneIn-Sender läuft und man schaut, ob eine Anfrage ankommt. Wenn du das auf deiner ST20 machen magst, nehme ich das Angebot gern an und schicke dir die Schritte.

Bis dahin ist „Aus" die richtige Einstellung.

[JRpersonal]

v1.0.1 leaves out the display push when the text on the display would not change (build).

Auf Deutsch: v1.0.1 lässt den Display-Push weg, wenn sich der Text auf dem Display nicht ändern würde (Build).

[meierchen006]

Hallo Jens @JRpersonal,

Danke für die Erklärung, und gut, dass der unnötige Push bei unverändertem Text in v1.0.1 wegfällt.

Den TuneIn-Test mache ich gern auf meiner ST20 (FW 27.0.6, jetzt STR v1.0.1). Schick mir bitte die Schritte. Mitschreiben kann ich das Agent-Log und den Netzverkehr der Box per SSH. Und falls ein bestimmter Sender als Testfall günstig ist, sag mir welcher.

[JRpersonal]

User offers to run the TuneIn test on his ST20 and asks for the steps.

Thanks for taking it on. The steps are below in German. They need the next release after v1.0.2, because only that one logs every request to the TuneIn host and fixes a duplicate catalogue entry that could otherwise break radio during the test. Everything is undone by deleting one file and restarting.

Auf Deutsch: Danke, dass du das übernimmst. Die Schritte brauchen das nächste Release nach v1.0.2, weil erst das jede Anfrage an den TuneIn-Host protokolliert und einen doppelten Katalogeintrag behebt, der sonst während des Tests das Radio stören könnte. Rückgängig machst du alles, indem du eine Datei löschst und neu startest.

1. Voraussetzung: das nächste Release nach v1.0.2 auf der ST20.
2. Per SSH nachsehen, ob es die Datei schon gibt: cat /mnt/nv/streborn/reflect-sources.json. Gibt es sie, sichere sie mit cp /mnt/nv/streborn/reflect-sources.json /mnt/nv/streborn/reflect-sources.json.bak und häng den TuneIn-Eintrag an das vorhandene Array an, statt sie zu überschreiben.
3. Gibt es sie nicht: echo '[{"source":"TUNEIN","account":"","name":"TuneIn"}]' > /mnt/nv/streborn/reflect-sources.json
4. Den Lautsprecher in der STR-App über „Lautsprecher neu starten“ neu starten.
5. Danach curl -s http://<IP-der-ST20>:8090/sources | grep -i TUNEIN, und notieren, ob TUNEIN auftaucht und mit welchem Status (READY oder UNAVAILABLE).
6. Log mitlaufen lassen: tail -f /mnt/nv/streborn/agent.log | grep -iE "TuneIn request|marge"
7. Lautstärke vorher niedrig stellen, dann 1LIVE über TuneIn starten: curl -s -X POST http://<IP-der-ST20>:8090/select -d '<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s25260" sourceAccount=""><itemName>1LIVE</itemName></ContentItem>' und die Antwort der Box notieren.
8. Drei bis vier Minuten laufen lassen, mindestens über einen Titelwechsel. Erscheinen im Log Zeilen „TuneIn request from the box“? Was zeigt curl -s http://<IP-der-ST20>:8090/now_playing bei track und artist? Zeigt das Display einen Titel, und gibt es beim Wechsel einen Aussetzer?
9. Danach eine Diagnosedatei speichern, mit dem Knopf „Diagnose-Log speichern“ ganz unten in der STR-App.
10. Rückgängig machen: rm /mnt/nv/streborn/reflect-sources.json (oder die .bak zurückkopieren) und den Lautsprecher wieder über die App neu starten.

Was die Ergebnisse bedeuten:

• TUNEIN fehlt oder steht auf UNAVAILABLE: Die Firmware registriert TuneIn nicht, der Weg ist zu.
• READY, aber Schritt 7 meldet einen Fehler und im Log steht keine TuneIn-Anfrage: Die Quelle spielt ohne Boses Backend nicht, der Weg ist zu.
• Anfragen an /bmx/tunein/...: Die Firmware spielt über Boses TuneIn-Adapter, den könnte STR nachbilden. Vielversprechend.
• Anfragen an den radiotime-Host (/profiles/.../nowPlaying, /Describe.ashx, /Tune.ashx): Der beste Fall, die Firmware holt Titel selbst ab. Beantwortet STR diese Anfragen, könnte das Display Titel ohne Aussetzer zeigen.

[meierchen006]

Hallo Jens @JRpersonal
Die Version 1.0.2 haben wir installiert.
„Wie du geschrieben hast, warte ich mit dem eigentlichen Test auf das Release nach v1.0.2 (TuneIn-Protokoll und Katalog-Fix). Sobald es da ist, spiele ich es auf und melde die Ergebnisse hier."

[JRpersonal]

User reports: the ST20 showed only "1LIVE" during the morning test, no show name like "Danger Zone" on the Portable, and offers to measure on the ST20.

That difference may be the time of day. TuneIn sends the current show as the second line, and not every 1LIVE slot has one; right now it says "Fuck Forward", in the morning it may be empty. The cheapest check is to open https://api.tunein.com/profiles/s25260/nowPlaying?partnerId=Bose in a browser while 1LIVE plays through TuneIn and compare Header.Subtitle with the display. If they match, the ST20 fetches it the same way as my Portable. I'm doing the host measurement on a spare speaker, because my Portable's web interface froze during the test yesterday.

---

Der Unterschied kann an der Uhrzeit liegen. TuneIn schickt als zweite Zeile die laufende Sendung, und nicht jede 1LIVE-Sendung hat da etwas stehen. Gerade steht dort „Fuck Forward“, morgens ist es vielleicht leer. Am einfachsten prüfst du das, indem du https://api.tunein.com/profiles/s25260/nowPlaying?partnerId=Bose im Browser öffnest, während 1LIVE über TuneIn läuft, und Header.Subtitle mit dem Display vergleichst. Stimmt beides überein, holt sich die ST20 das genauso wie meine Portable. Die Messung, welchen Host der Lautsprecher nutzt, mache ich auf einem Ersatzlautsprecher, weil die Weboberfläche meiner Portable gestern beim Test eingefroren ist.

[JRpersonal]

v1.0.3 (build) is out and logs every request to the TuneIn host, so the test steps above can run now.

Auf Deutsch: v1.0.3 (build) ist draußen und protokolliert jede Anfrage an den TuneIn-Host, die Testschritte oben kannst du also jetzt durchgehen.

[JRpersonal]

User reports: TuneIn test on an ST20 with v1.0.3: TUNEIN shows as READY, but selecting a station fails with BMX_JSON_PARSE_ERROR 4502 and no TuneIn request appears in the log.

The speaker asked STR's remote port for /bmx/tunein/v1/playback/station/s25260. STR had no route there, so it answered with the remote's web page, and the speaker could not read that as JSON. That port logged nothing, which is why the request was missing from your log. v1.0.4 (build) answers that route with the station's stream from TuneIn and logs every request the speaker makes under /bmx/. Whether the speaker accepts that answer and plays is untested, so a rerun of your test with v1.0.4 would settle it.

---

Der Lautsprecher hat beim Fernbedienungs-Port von STR nach /bmx/tunein/v1/playback/station/s25260 gefragt. Dafür hatte STR keine Route und hat mit der Webseite der Fernbedienung geantwortet, die der Lautsprecher nicht als JSON lesen konnte. Dieser Port hat nichts protokolliert, deshalb fehlte die Anfrage in deinem Log. v1.0.4 (build) beantwortet diese Route mit dem Stream des Senders von TuneIn und protokolliert jede Anfrage des Lautsprechers unter /bmx/. Ob der Lautsprecher das annimmt und spielt, ist noch ungetestet. Ein zweiter Durchlauf deines Tests mit v1.0.4 würde es klären.

[meierchen006]

Hallo Jens @JRpersonal,

zweiter Durchlauf mit v1.0.4 auf der ST20 (FW 27.0.6), heute 08:20 bis 08:32. Kurz: TuneIn spielt jetzt, der Liedtitel holt sich die Box aber nicht.

Ablauf: reflect-sources.json angelegt, Neustart über die App, TUNEIN wieder READY. 08:24:10 dein /select für 1LIVE (s25260), Lautstärke 10.

08:24:09.604 box ws: source changed  from=LOCAL_INTERNET_RADIO to=TUNEIN
08:24:11.090 bmx tunein: station resolved  path=/bmx/tunein/v1/playback/station/s25260 id=s25260 name=1LIVE
             streamHost=wdr-1live-live.icecastssl.wdr.de
08:24:11.093 bmx: request from the box on the webui port  method=GET path=/bmx/tunein/v1/playback/station/s25260
             userAgent=Bose_Lisa/27.0.6  status=200  response={"audio":{"hasPlaylist":false,"isRealtime":true,"streamUrl":…
08:24:11.801 stream proxy raw start  url=https://wdr-1live-live.icecastssl.wdr.de/…/stream.mp3?aggregator=tunein  ua=Bose/7.22.0  icyReq=""
08:24:13.456 box syslog: marge_error  "AddRecentCB Failed with status=200"
08:24:16.432 stream proxy ICY negotiation  boxWantsICY=false  upstreamMetaint=16384
08:24:16.493 stream proxy ICY title  "Teddy Swims - Mr. Know It All"
08:26:49.805 stream proxy ICY title  "Tyla - CHANEL"
08:29:49.876 stream proxy ICY title  "1LIVE"   (Nachrichten)

now_playing: source="TUNEIN", streamType=RADIO_STREAMING, itemName/track/stationName = „1LIVE", artist leer.

Beobachtung am Gerät:

• Ton kommt, sauber, keine Unterbrechung über zwei Liedwechsel und den Übergang zu den Nachrichten.
• Display zeigt durchgehend nur „1LIVE", nie einen Liedtitel.

Was die Box angefragt hat: über die ganzen ~8 Minuten genau eine Anfrage, die /bmx/tunein/v1/playback/station/s25260 beim Start. Danach nichts mehr unter /bmx/, auch nicht bei den Liedwechseln. 0× „TuneIn request from the box" (radiotime). Im Datenstrom fragt sie auch hier kein ICY an (icyReq="", boxWantsICY=false).
→ Auf diesem Weg holt sich die Firmware den Titel also nicht selbst. Ob sie es täte, wenn die Playback-Antwort mehr enthielte (z.B. eine nowPlaying-/Metadaten-Adresse im JSON), kann ich nicht beurteilen. Falls du eine Antwort mit zusätzlichen Feldern ausprobieren möchtest, teste ich gern wieder.

Zwei Nebenbefunde:

1. marge_error "AddRecentCB Failed with status=200" direkt nach dem Start: Die Box wollte den Sender wohl in „Zuletzt gehört" eintragen und mochte die Antwort nicht.
2. 08:29:16, genau 5 Minuten nach dem Start, schrieb STR die Stationstasten trotz laufender Wiedergabe neu:
   preset reconcile: forced pass ran anyway, the hold ceiling passed … reason=playing source=TUNEIN heldFor=5m1s
   Dabei meldete die Box source changed from=TUNEIN to=LOCAL_INTERNET_RADIO. Der Ton-Datenstrom lief aber weiter (kein neuer stream proxy start, kein end), now_playing stand danach wieder auf TUNEIN, und ich habe keinen Aussetzer gehört. Nur zur Info, falls die Quellenmeldung woanders etwas auslöst.

Rückbau: Log gesichert (hängt an), reflect-sources.json gelöscht, Neustart über die App.

agent-ST20-TuneIn-Test2-bereinigt.log

Viele Grüße
Andreas

[JRpersonal]

User reports: TuneIn on the ST20 with v1.0.4 plays without a gap, but the display shows only the station name; the speaker made one request at the start and none after.

That settles the first half. The firmware's TuneIn client knows a now-playing address (its strings carry a nowPlayingUri and a /nowPlaying?partnerId= route), so the next step is to put such an address into the station answer and see whether the speaker starts asking it for titles. That is untested guesswork about Bose's format, and a test build would show it. The failed "recently played" entry does no harm. The forced preset pass after five minutes is the deliberate ceiling of the hold, and the source flip it causes stayed silent, as you heard.

---

Damit ist die erste Hälfte geklärt. Der TuneIn-Client der Firmware kennt eine Now-Playing-Adresse (in seinen Strings stehen ein nowPlayingUri und eine Route /nowPlaying?partnerId=). Als Nächstes käme so eine Adresse in die Antwort zum Sender, dann zeigt sich, ob der Lautsprecher dort nach Titeln fragt. Das ist ungetestet und eine Vermutung über Boses Format, ein Testbuild würde es zeigen. Der fehlgeschlagene Eintrag in „Zuletzt gehört“ schadet nicht. Der erzwungene Preset-Durchgang nach fünf Minuten ist die gewollte Obergrenze fürs Warten, und der Quellenwechsel dabei blieb stumm, wie du gehört hast.

[JRpersonal]

User reports: asked for the next step after TuneIn played without a gap but showed only the station name.

I ran the experiment on my Portable. The speaker never asked the now-playing address STR offered. It fetches now-playing itself, straight from TuneIn: "Danger Zone" on the display is the current 1LIVE show from TuneIn's profiles/<id>/nowPlaying service, and TuneIn has no song titles for 1LIVE. Next I'll measure which TuneIn host the speaker uses, then let STR answer it with the song from the stream.

---

Ich habe das Experiment auf meiner Portable gemacht. Die Now-Playing-Adresse von STR hat der Lautsprecher nie abgefragt. Er holt sich Now-Playing selbst, direkt bei TuneIn. „Danger Zone" auf dem Display ist die aktuelle 1LIVE-Sendung aus TuneIns Dienst profiles/<id>/nowPlaying, und Songtitel hat TuneIn für 1LIVE keine. Als Nächstes messe ich, welchen TuneIn-Host der Lautsprecher nutzt, und lasse STR dann mit dem Song aus dem Stream antworten.

[meierchen006]

Hallo Jens @JRpersonal,

danke für den Portable-Test, das ist eine gute Spur.
Ein Unterschied zu meiner ST20 fällt mir dabei auf und hilft vielleicht bei deiner Messung:

Bei meinem Test 2 (v1.0.4, heute 08:24 bis 08:32) stand auf dem Display der ST20 die ganze Zeit nur „1LIVE", also kein Sendungsname wie „Danger Zone" bei dir. Auch now_playing lieferte nur itemName/track/stationName = „1LIVE", artist leer.
Im Agent-Log gab es in den 8 Minuten keine einzige „TuneIn request from the box".

Zwei mögliche Erklärungen, die ich nicht unterscheiden kann:

1. Die ST20 erreicht TuneIn für Now-Playing gar nicht. In ihrer /etc/hosts steht der STR-Block mit
   127.0.0.1 7f5055e9…f4.api.radiotime.com (plus streaming.bose.com und content.api.bose.io). Falls Now-Playing über genau diesen Host läuft, landet die Anfrage bei STR, aber vielleicht auf einem Port, der nicht protokolliert. Oder die Box gibt nach einem Fehler still auf.
2. Die ST20 (Lisa 27.0.6) fragt Now-Playing anders oder gar nicht ab als die Portable.

Wenn es dir hilft, messe ich auf der ST20 mit, nur lesend per SSH: welche Namen die Box beim TuneIn-Abspielen auflöst und zu welchen Adressen und Ports sie Verbindungen aufbaut (netstat, die Bose-Logs). Sag mir gern, worauf ich achten soll, oder schick mir die Schritte für deine Messung, dann mache ich sie hier parallel zur Portable.

Viele Grüße
Andreas

[meierchen006]

Hallo Jens @JRpersonal,

Danke für den Hinweis mit der Uhrzeit, ich habe es eben nachgeprüft. Die Uhrzeit ist es nicht.

Heute 08:27–08:32, ST20, STR v1.0.4,
gleicher Ablauf wie gestern (reflect-sources.json, Neustart über die App, TUNEIN READY, /select 1LIVE s25260).

• TuneIn (https://api.tunein.com/profiles/s25260/nowPlaying?partnerId=Bose, 08:22 und 08:28 abgefragt): Header.Title = „1LIVE", Header.Subtitle = „A-Section" (Secondary „A-Section", SecondsLeft 5918, Ttl 913).
• Display der ST20: nur „1LIVE" mit dem STR-Logo darüber, kein „A-Section" (Foto hängt an).

• now_playing der ST20: source="TUNEIN", PLAY_STATE, itemName/track/stationName = „1LIVE", artist/album leer.
• Agent-Log: wie gestern genau eine Anfrage /bmx/tunein/v1/playback/station/s25260 (Bose_Lisa/27.0.6), danach nur Stream-Proxy und AddRecentCB Failed. Nichts Richtung Now-Playing.

Die ST20 holt den Sendungsnamen also nicht, anders als deine Portable. Auf der ST20 steht in /etc/hosts nur der STR-Block

127.0.0.1  streaming.bose.com
127.0.0.1  content.api.bose.io
127.0.0.1  7f5055e9…f4.api.radiotime.com

Falls die Lisa-Firmware Now-Playing über genau diesen radiotime-Host abfragt, landet es bei STR, ohne Antwort und ohne Logzeile.
Bei der Portable dagegen vielleicht nicht, weil dort ein anderer Host oder kein Eintrag ist? Für deine Host-Messung auf dem Ersatzlautsprecher wäre die ST20 damit ein guter Gegenpol. Wenn du mir sagst, worauf ich achten soll, messe ich hier gern mit.

Rückbau erledigt, Box wieder im Normalbetrieb.

agent-ST20-TuneIn-Test3-bereinigt.log

Gruß
Andreas

[JRpersonal]

User reports: the time of day is ruled out. At 08:28 TuneIn listed "A-Section" as the subtitle, while the ST20 showed only "1LIVE" and made no now-playing request at all.

The hosts line is ruled out too. A request to that radiotime host would land on STR and show up in the log as "TuneIn request from the box", and my Portable has the same line. The difference is the build. My Portable ran a test build whose station answer tells the speaker where now-playing lives (nowPlayingUri), and your v1.0.4 sends nothing like it. The speaker never called STR's address, but that field may be what starts its own fetch from TuneIn. That field is in v1.0.8 (build) now, so the next step is your test 3 again on that version.

---

Die Uhrzeit ist es nicht, und die Zeile in /etc/hosts auch nicht. Eine Anfrage an diesen radiotime-Host würde bei STR landen und im Log als „TuneIn request from the box“ auftauchen, und meine Portable hat dieselbe Zeile. Der Unterschied ist der Build. Auf meiner Portable lief ein Testbuild, dessen Antwort zum Sender dem Lautsprecher sagt, wo es Now-Playing gibt (nowPlayingUri), und deine v1.0.4 schickt so etwas nicht mit. Die Adresse von STR hat der Lautsprecher nie abgefragt, aber vielleicht ist genau dieses Feld der Anstoß, dass er selbst bei TuneIn nachfragt. Dieses Feld ist jetzt in v1.0.8 (build) drin, als Nächstes also dein Test 3 noch einmal mit dieser Version.

[meierchen006]

Hallo Jens @JRpersonal,

Test 3 noch einmal mit v1.0.8 auf der ST20 (FW 27.0.6), heute 11:06 bis 11:18. Jetzt kommt der Sendungsname.

• Vorab: nowPlayingUri steckt im v1.0.8-Agent. TuneIn meldete um 11:03 Header.Subtitle = „B-Section".
• Dein Log beim Start zeigt das neue Feld:
  bmx tunein: station resolved … name=1LIVE … nowPlaying=/v1/now-playing/station/s25260
• Die Box hat diese STR-Adresse nicht abgefragt (keine Logzeile), hatte aber ab 11:07:05 den Sendungsnamen. now_playing: track=„1LIVE", artist=„B-Section", album leer.
• Display der ST20: „1LIVE" und „B-Section" im Wechsel in derselben Zeile.
• Die Bose-Firmware protokolliert es selbst (Syslog, logread):

  STSIPC(TUNEIN, '')::SendNowPlayingResponse(seq:152, proto{ nowPlaying { contentItem { type: "stationurl",
    location: "/v1/playback/station/s25260", name: "1LIVE" }, trackName: "1LIVE", artistName: "B-Section",
    albumName: "", stationName: "1LIVE", artUrl: "http://cdn-profiles.tunein.com/s25260/images/logog.jpg?t=…",
    playStatus: PLAY, streamType: RADIO_STREAMING … })
  BMX(): HandleNowPlayingRequest() >> LiveRadioStreaming > LiveRadioPlaying > LiveRadio > Active
  

Host-Messung (lesend, netstat -tn auf der Box, während TuneIn spielte):

ESTABLISHED  192.168.156.40:48096 -> 104.17.106.184:80

104.17.106.184 ist bei mir die Adresse von opml.radiotime.com und api.radiotime.com (beide gleich, Cloudflare). Keine Verbindung zu api.tunein.com/feed.tunein.com (104.18.34.155). Die Box holt Now-Playing also per HTTP auf Port 80 bei radiotime.com, nicht über den umgeleiteten 7f5055e9…api.radiotime.com. Welcher der beiden Namen und welcher Pfad, steht nicht im Bose-Syslog, der Ringpuffer reicht nur wenige Minuten. Da es unverschlüsselt ist, sollte sich der Name per /etc/hosts auf STR umleiten lassen.

Zur Anzeige: Die ST20 wechselt beim TuneIn-Weg zwischen stationName („1LIVE") und artistName („B-Section"), jeweils als ganzer, zentrierter Text. Lange Texte bricht sie um (wie „SR3 / Saarlandwelle / 128k" oder beim UPnP-Push „Sie hören … mit …"). Wenn STR später den Song liefert, würde er auf der ST20 also im Wechsel mit dem Sendernamen erscheinen, bei langen Titeln umgebrochen.

Keine Aussetzer. Um 11:11:40 wieder der gewollte Preset-Durchgang nach 5 min (TUNEIN → LOCAL_INTERNET_RADIO gemeldet, stumm). Rückbau erledigt.

agent-ST20-TuneIn-Test4-bereinigt.log

box-NowPlayingResponse-Auszug.txt

Wir installieren jetzt die Version 1.0.9

Viele Grüße
Andreas

[JRpersonal]

User reports (German): on v1.0.8 the ST20 now shows the show name alternating with the station, and netstat showed a port-80 connection to radiotime.com.

Your test confirms that since v1.0.8 the ST20 fetches the show name itself. The port-80 connection to radiotime.com may be STR's own, though, because the agent resolves stations at opml.radiotime.com and keeps that connection open. netstat -tnp shows which program owns each connection (streborn or BoseApp). Could you run it while TuneIn plays, ideally across a show change? A hosts redirect only makes sense once we know which host the speaker itself asks.

---

Dein Test bestätigt, dass die ST20 seit v1.0.8 den Sendungsnamen selbst holt. Die Verbindung zu radiotime.com auf Port 80 kann aber von STR selbst stammen, denn der Agent löst Sender über opml.radiotime.com auf und hält die Verbindung offen. netstat -tnp zeigt zu jeder Verbindung das Programm (streborn oder BoseApp). Kannst du das laufen lassen, während TuneIn spielt, am besten über einen Sendungswechsel hinweg? Ein Umleiten per hosts-Datei lohnt sich erst, wenn klar ist, welchen Host der Lautsprecher selbst fragt.

[meierchen006]

Hallo Jens @JRpersonal,

du hattest recht, die offene Port-80-Verbindung war STRs eigene. Ich habe heute mit netstat -tnp gemessen, ST20 auf v1.0.9, diesmal mit SR3 über TuneIn (s1308), 08:07 bis 09:10, über einen Sendungswechsel um 09:00. Alle 10 s netstat -tnp (nur Verbindungen außerhalb 127.x) und now_playing, jede Minute api.tunein.com/profiles/s1308/nowPlaying?partnerId=Bose.

Anzeige: Sofort „SR 3 Saarlandwelle" ↔ „Guten Morgen" im Wechsel (artist=„Guten Morgen"), wie bei 1LIVE. Es geht also senderunabhängig.

Alle Verbindungen zu radiotime (104.17.106.184 / 104.17.107.184, Port 80), je erste Sichtung:

08:07:46 ESTABLISHED 192.168.156.40:53834 -> 104.17.107.184:80 2934/streborn-armv7   (Start, select)
08:07:46 TIME_WAIT   192.168.156.40:53845 -> 104.17.107.184:80 -
08:19:00 ESTABLISHED 192.168.156.40:41212 -> 104.17.107.184:80 2934/streborn-armv7   (Fortsetzen nach Pause)
08:19:00 TIME_WAIT   192.168.156.40:41219 -> 104.17.107.184:80 -
08:34:21 TIME_WAIT   192.168.156.40:53660 -> 104.17.106.184:80 -
08:49:28 TIME_WAIT   192.168.156.40:60754 -> 104.17.107.184:80 -
09:00:07 TIME_WAIT   192.168.156.40:50140 -> 104.17.106.184:80 -

• Die offenen Verbindungen gehören streborn-armv7, deine Vermutung stimmt.
• Daneben gibt es kurze Verbindungen (beim 10-s-Takt nur noch als TIME_WAIT zu sehen, also ohne Programmnamen) um 08:34:21, 08:49:28 und 09:00:07. In diesen Minuten steht im Agent-Log nichts, auch kein station resolved.
• Abstand 08:19 → 08:34 → 08:49: etwa 15 Minuten, passend zu TuneIns Ttl (913 s).
• 09:00:07 genau beim Sendungswechsel: now_playing sprang im selben 10-s-Fenster von „Guten Morgen" auf „Hören was ein Land fühlt". TuneIns API zeigte das bei meiner Minutenabfrage erst um 09:00:50, ab 09:04 dann „Bunte Funkminuten". Die Box blieb bis 09:10 bei „Hören was ein Land fühlt" und zeigte erst danach „Bunte Funkminuten" (im Bose-Syslog ab 09:17:27 so, der Ringpuffer reicht nicht weiter zurück), also wieder etwa 15 Minuten nach dem Abruf um 09:00:07. Sie fragt nach eigenem Takt und nicht laufend.

Meine Lesart: Die kurzen Verbindungen sind sehr wahrscheinlich der Now-Playing-Abruf der Firmware (STSCertified/BMX), über HTTP Port 80 bei radiotime.com. Beide Cloudflare-Adressen kommen vor, also opml.radiotime.com oder api.radiotime.com. Bewiesen ist der Programmname nicht, dafür war der 10-s-Takt zu grob. Die Bose-Firmware selbst loggt nur das Ergebnis (SendNowPlayingResponse … artistName), nicht die URL, und ihr Ringpuffer reicht keine 10 Minuten zurück.

Nachmessung mit 1LIVE, 09:20 bis 10:20, direkt auf der Box alle 0,3 s (netstat -tnp, nur Port 80 nach außen):

09:21:03 ESTABLISHED :60764 -> 104.17.107.184:80 2934/streborn-armv7   (select; zuletzt gesehen 09:27:20, danach zu)
09:36:07 TIME_WAIT   :50603 -> 104.17.107.184:80 -
09:51:25 TIME_WAIT   :42916 -> 104.17.106.184:80 -
10:00:23 TIME_WAIT   :46057 -> 104.17.107.184:80 -     (TuneIn-Sendungswechsel laut SecondsLeft 09:59:59)
10:15:33 TIME_WAIT   :58282 -> 104.17.106.184:80 -

now_playing sprang um 10:00:25 von „A-Section" auf „B-Section", 2 s nach der Verbindung um 10:00:23. STR hatte ab 09:27:20 keine radiotime-Verbindung mehr, und im Agent-Log steht von 09:35 bis 10:17 nichts zu radiotime/TuneIn/bmx. Die kurzen Verbindungen kommen also von der Firmware: beim Start, alle ~15 min (Ttl) und beim Sendungsende (SecondsLeft). Selbst im 0,3-s-Takt sieht netstat sie nur noch als TIME_WAIT, die Abfrage dauert also unter 0,3 s, daher kein Programmname.

Für deinen Plan heißt das: radiotime, HTTP Port 80, Abruf beim Start, alle ~15 min und beim Ablauf von SecondsLeft. Wenn STR einen Song liefert, könnte es über ein kurzes SecondsLeft (bis zum vermuteten Songende oder ein fester kurzer Wert) die Box schneller nachfragen lassen. Sonst kommt ein neuer Titel erst bis zu 15 min später.

1LIVE-netstat-port80-Zusammenfassung.txt
1LIVE-now_playing.log
1LIVE-tunein.log
SR3-netstat-radiotime-Verbindungen.txt
SR3-now_playing.log
SR3-tunein.log

Rückbau erledigt, Box wieder im Normalbetrieb.

Viele Grüße
Andreas

[JRpersonal]

User reports (German): netstat on the ST20 shows that the open connection to radiotime belongs to STR, while the firmware itself makes short HTTP requests on port 80 to radiotime at station start, about every 15 minutes (TuneIn's Ttl) and when SecondsLeft runs out.

That settles which side asks. Plain HTTP on port 80 is the good news, because a redirected host then needs no certificate. The next step on my side is a test build that points the radiotime host at STR, answers the now-playing request with the song from the stream's ICY title and a short SecondsLeft so the speaker asks again at the next song, and passes every other request through to TuneIn.

Thanks for the measurement, the 0.3 s loop and the cleanup afterwards. That saved me a round of guessing.

---

Damit ist klar, wer fragt. Dass es reines HTTP auf Port 80 ist, ist die gute Nachricht, denn ein umgeleiteter Host braucht dann kein Zertifikat. Als Nächstes baue ich eine Testversion, die den radiotime-Host auf STR zeigen lässt, die Now-Playing-Anfrage mit dem Songtitel aus dem ICY-Titel des Streams und einem kurzen SecondsLeft beantwortet, damit der Lautsprecher beim nächsten Song wieder fragt, und alle anderen Anfragen an TuneIn durchreicht.

Danke für die Messung, die 0,3-s-Schleife und den sauberen Rückbau danach. Das hat mir eine Runde Raten erspart.

[JRpersonal]

Shipped in v1.0.13 on every SoundTouch with a display (20, 30, Portable and Wave): STR now draws the title on the display itself, so the stream is never restarted and the gap at every song change is gone. Switch it on in the speaker's settings in the app ("Show the current track on the speaker display"). Screenshots are in #1305. Tell me how it works for you.

Seit v1.0.13 auf jeder SoundTouch mit Display (20, 30, Portable und Wave): STR schreibt den Titel jetzt selbst aufs Display. Der Stream wird dafür nie neu gestartet, und die Lücke bei jedem Titelwechsel ist weg. Einschalten kannst du das in den Lautsprecher-Einstellungen in der App ("Aktuellen Titel am Lautsprecher-Display anzeigen"). Screenshots findest du in #1305. Sag mir gern, wie es bei dir läuft.

[meierchen006]

Hallo Jens @JRpersonal,

gute Nachricht: Auf meiner ST20 (FW 27.0.6) läuft die neue Anzeige mit v1.0.13 bereits. Einstellung An / Beides / Uhrzeit An. Im Log display track overlay on comp=oled. SR3 und SR1 laufen über LOCAL_INTERNET_RADIO, es gibt kein display push mehr, und der Liedwechsel läuft ohne Unterbrechung. Sendername läuft durch, Uhrzeit, Interpret und Titel wie bei der Portable (Bildschirmfotos hängen an).

Auch keine Unterbrechung bei einem Liedwechsel mehr!!!

So gut war das Bose ST20 Radio noch nie!!

Danke!
Andreas

[Duayne2001]

Same here on my 1st gen ST20 (FW 27.0.6). Fantastic job, thank you so much @JRpersonal!

[JRpersonal]

User reports (German): the new track screen runs on the ST20 with v1.0.13, no more gap at song changes, screenshots attached.

This is the confirmation I didn't have yet for the ST20. You carried this for weeks with the TuneIn measurements, netstat across a show change and every test build, and without that groundwork I'd still be patching the old re-buffer path. Thank you.

---

Das ist die Bestätigung, die mir für die ST20 noch gefehlt hat. Du hast das wochenlang getragen, mit den TuneIn-Messungen, netstat über einen Sendungswechsel und jedem Testbuild, und ohne diese Vorarbeit würde ich immer noch am alten Weg mit dem Neupuffern flicken. Danke dir.

[meierchen006]

Die größte Leistung hast du erbracht

[frumshey]

Whow! Looks stunning! Thanks to both of you! Agree, my Soundtouch (also a ST20 (FW 27.0.6)) was never so good as it is now :-)