66 comments

• Hello,
  Very happy to find this page. I have a Soundbridge that has played it’s last streaming station due to everything moving to https. I’ve been working on using nginx on a pi3 as a reverse proxy but keep running into various errors. Would you be willing to share your entire nginx config with me please?
  Thank you.

  • Hi Paul, Nice to hear, that you will rescue your SoundBridge too. I thought the code for nginx in my post but I will ask my coder if there is something more you have to deal with.

• Paul here again, got it working! Your config bits work perfectly, had some basic nginx config missing. The other missing piece was decoding the correct url’s for the streams. Right clicking on a streaming web page and using „inspect element“ lets me find the URL, then I can use VLC to test it before putting it in the soundbridge. Thanks again for this page and documentation.

  • Hey Paul, Congrat to your persistence and success, this will make my day. If you like, share your experience and maybe it will help other owners to rescue their SoundBridges too. Best regards and take care at yourself.

  • And a question from me: how did you find my article? I had posted Link to my solution at https://en.wikipedia.org/wiki/SoundBridge

    But a day later the link had been deleeted by a wiki-admin.

• Hallöchen,

  klingt gut! Ich hab zu dem HTTPS aber noch das Problem, das Radiosender wie z.B. “Radio Arabella” aus München nicht mehr empfangbar sind mit der Soundbridge. Verbindung wird hergestellt, aber Stream bricht sofort wieder ab, Neuverbindung, kurzer Ton, Abbruch usw.! Dafür vielleicht auch eine Idee? Stream-URL wäre http://live.radioarabella.de/stream
  Soundbridges sind auch heute noch uptodate! Ich hab (jetzt muss ich echt überlegen) 4 aktiv in Gebrauch und 2 als Reserve.

  • Hi, ich werde die Adresse die Tage mal bei meiner Soundbridge prüfen und meine mich zu erinnern, dass ich das Problem auch mal hatte. Aber seit dem ich nicht mehr direkt über das Wlan der Soundbridge sondern über den Umweg Lan zu Mediabridge gehe, das Problem nicht mehr aufgetaucht ist. Wenn ich die Adresse geprüft habe, melde ich mich nochmal. Grüsse #Martin

• Hallo,

  die Idee ist super und ließ sich auch leicht umsetzen. Mein Problem ist, dass in allen Playlists, zu denen ich die Links habe, Weiterleitungen zum eigentlichen Stream stehen. Und diese Weiterleitungen enthalten wieder https.

  Beispiel:
  https://stream.absolutradio.de/lq/mp3/Fritzbox.m3u hab ich im Preset konfiguriert als
  http://192.168.1.30:81/radio/stream.absolutradio.de/lq/mp3/Fritzbox.m3u
  Lade ich mir das m3u direkt herunter, steht dort https://sec-absolut.hoerradar.de/absolutradio-mp3-128?sABC=60o899sn%230%236n924132s76317r57235r93rss45n4ps%23&=&amsparams=playerid:;skey:1622710778 drin. Und dieser https-Stream wird natürlich nicht umgesetzt. Das äußert sich in der Anzeige von “Wiederhole Verbindung zu Server …” in der Soundbridge bzw. zu immer gleichen Logeinträgen in /var/log/nginx/access.log:
  192.168.1.18 – – [03/Jun/2021:10:29:36 +0200] “GET /radio/www.di.fm/vocaltrance HTTP/1.0” 200 28697 “-” “Roku SoundBridge/3.0”

  Hier meine Config:
  server {
  listen 81;

  location ~ ^/radio/(.*) {
  resolver 8.8.8.8;
  proxy_pass https://$1; # uses regular expression from above, inserts postfix (after /radio/) as url
  client_max_body_size 0; # for streaming content: disables checking of client body size
  proxy_buffering off; # for streaming content
  proxy_ssl_server_name on;
  }
  }

  VG
  Stephan

  • Hi Stephan,
    mein Coder hatte etwas Zeit und die Konfig überarbeitet (siehe oben in meinem Beitrag).

    Seine Analyse:
    “Das Problem besteht darin, dass die genannte Adresse eine “m3u”-Playlist zurückliefert, und dass die hierin enthaltene(n) Adressen so angepasst werden müssen, dass sie den Raspberry-Proxy verwenden. (Abschnitt a)
    Zusätzlich gab es noch ein Verbindungs-Problem mit der genannten Adresse (“SSL_do_handshake() failed…”), das habe ich dann gleich mit erledigt. (Abschnitt b)”

    Grüße

    Martin

    • Ich habe es mittlerweile selber hinbekommen, indem ich 3 weitere Zeilen in der nginx-Config eingebaut habe:
      sub_filter_once off;
      sub_filter_types *;
      sub_filter “https://” “http://192.168.1.30:81/soundbridge/”;

      Damit wird ein Input-Content-Filter eingerichtet, der alle https-Links im Response wieder auf http und den nginx-Server umleitet. Funzt super.
      Vieleicht nützt es ja auch jemanden anderen. Hier nochmals meine komplette Config (auf der 192.168.1.30 läuft mein nginx):

      # Roku proxy configuration
      #
      server {
      listen 81;
      access_log off;
      error_log off;
      #root /var/www/html;
      #index index.html indem.htm index.nginx-debian.html;

      #server_name rokuproxy;

      location ~ ^/soundbridge/(.*) {
      resolver 8.8.8.8;
      proxy_pass https://$1; # uses regular expression from above, inserts postfix (after /radio/) as url
      client_max_body_size 0; # for streaming content: disables checking of client body size
      proxy_buffering off; # for streaming content
      proxy_ssl_server_name on;
      sub_filter_once off;
      sub_filter_types *;
      sub_filter “https://” “http://192.168.1.30:81/soundbridge/”;
      }
      }

      VG
      Stephan

• Hallo Stephan, mit dieser nginx config erhalte ich, wenn ich die IP aufd er nginx läuft eingebe:
  Welcome to nginx!
  If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
  For online documentation and support please refer to nginx.org.
  Commercial support is available at nginx.com.
  Thank you for using nginx.
  Raspi ist noch relativ neu für mich. Hast einen Tip für mich?

  • Hallo Christian,

    das ist schon so Ok. Du rufst ja den nginx einfach nur so auf. Wenn Du wirklich meine Config hast, dann springt der nur an, wenn ein „soundbridge“ in der URL steht (bzw. ein „radio“, falls Du die Originalconfig von ganz oben auf dieser Seite hast).

    Wenn Du also eine Radio-Streaming-URL hast, wie z.B.https://stream.absolutradio.de/lq/mp3/Fritzbox.m3u
    dann solltest Du in den Presets der Soundbridge stattdessen folgendes eintragen:http://IP-von-Nginx:81/soundbridge/stream.absolutradio.de/lq/mp3/Fritzbox.m3u

    Damit sollte dann Dein nginx anspringen und alles, was nach „soundbridge/“ kommt abholen und Dir bzw. der Soundbridge zur Verfügung stellen. Sollte übrigens auch mit dem Browser funktionieren, dass er das m3u runterlädt, welches sich z.B. mit VLC öffnen lässt.

    Bitte beachte auch, dass in meiner obigen Config die IP und der Port des Nginx bei sub_filter stehen muss!

    VG
    Stephan

    • Hallo Stephan, danke für Deine rasche Antwort. Habs mittlerweile hinbekommen. Hab den Raspi einfach nochmal ganz neu aufgesetzt, nur Update und Upgrade ausgeführt und nginx installiert und mit Deiner Config versehen. Funktioniert wunderbar.
      VG
      Christian

• Hi MIND WORK
  I tried your nginx.conf file but I get this access log

  192.168.7.27 – – [26/Dec/2021:17:26:36 +0100] “GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0” 200 65795 “-” “Roku SoundBridge/3.0”
  192.168.7.27 – – [26/Dec/2021:17:26:37 +0100] “GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0” 200 65683 “-” “Roku SoundBridge/3.0”
  192.168.7.27 – – [26/Dec/2021:17:26:38 +0100] “GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0” 200 65795 “-” “Roku SoundBridge/3.0”

  my soundbridge is looping , beginning a connection every second, playing half a second sound and then back to connecting again.
  any help would be appreciated to save my M1001 !

  would you share a complete nginx.conf working file?

  regards
  Alex

• hello Mind Work ! is this trick still working on a M1001 ? I tried your nginx.conf file and now, my soundbrige can connect to the https radio url but when the buffer reaches 100%, playing won’t start , it seems connexion is closed and initialized again, buffer filling starts again from 0% to 100% ,looping that way , any idea? thanks !

  • Hi Alex, sorry for the delay but I am on vacation and only unregular online. I can share your request with my coder and maybe he can find a fix. But before I will do this the question is if you are sure that you copy my setup and the code exactly. Beware that I have connected my Soundbridge to my network via Lan and only then I do connect it to the electricity and power it up. If you will not follow this order, the SoundBridge will use the build-in old Wi-Fi 802.11b and this can be the first reason for disconnections. So check this and come back, if this will not work. Best and take care of yourself. Martin

• Hi Alex,
  please try/use my config above, which I have posted on June, 3. and fixed with additional things on August, 13. Sorry for the post above in german. Let me know, if you have problems with it.
  Regards
  Stephan

• Hi Martin ! thanks for your help!
  I checked I’m really on ethernet LAN not wifi.
  I still have the issue with this kind of url : https://audio.bfmtv.com/bfmbusiness_128.mp3
  with access-log on option I could trace the following connection attempts (I can hear the radio for 0.25 second every 2 or 3 seconds…chopped sound.
  192.168.7.14 – – [04/Jan/2022:21:43:59 +0100] „GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0“ 200 28560 „-“ „Roku SoundBridge/3.0“
  192.168.7.14 – – [04/Jan/2022:21:44:00 +0100] „GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0“ 200 65683 „-“ „Roku SoundBridge/3.0“
  192.168.7.14 – – [04/Jan/2022:21:44:01 +0100] „GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0“ 200 28560 „-“ „Roku SoundBridge/3.0“
  192.168.7.14 – – [04/Jan/2022:21:44:02 +0100] „GET /radio/audio.bfmtv.com/bfmbusiness_128.mp3 HTTP/1.0“ 200 28560 „-“ „Roku SoundBridge/3.0“
  here is my complete nginx.conf file and I got the same result with Stephan’a file published here on last august 13th.
  all best and happy new year!
  # Roku proxy configuration
  #
  events {
  worker_connections 4096; ## Default: 1024
  }
  http {
  server {
  listen 81;
  location ~ ^/radio/(.*) {
  resolver 8.8.8.8 valid=30s; # works somehow only with resolver, which could also be the docker internal resolver: 127.0.0.11 (not tested)
  proxy_pass https://$1;
  client_max_body_size 0; # 0 disables checking client body size; could alternatively be 2m or 10m
  proxy_buffering off;
  # handle responses containing m3u playlists (content-type audio/x-mpegurl, etc)
  # returned for example by this address: https://stream.absolutradio.de/lq/mp3/Fritzbox.m3u
  # a) in case of m3u responses / playlist files (and also html and text responses), rewrite urls in the response body:
  sub_filter ‚https://‘ ‚http://192.168.7.28:81/radio/‘;
  sub_filter_types text/html, text/plain, audio/x-mpegurl, audio/mpegurl, application/m3u, audio/x-mp3-playlist, audio/m3u, audio/x-m3u;
  sub_filter_once off;
  # b) avoid error “SSL_do_handshake() failed…”, which might be a special case concerning the tested host (stream.absolutradio.de),
  # see https://stackoverflow.com/questions/25329941/nginx-caching-proxy-fails-with-ssl23-get-server-hellosslv3-alert-handshake-fail/25330027#25330027
  proxy_ssl_server_name on;
  proxy_ssl_protocols TLSv1.2;
  }
  }
  }

• Hey Alex, in August Stephan posted a comment with a modified coding version. Try this and if this helps it will be great. If it will not fix your errors I will be back end of next week and ask my coder about your lines. Best, Martin.

• Hi Martin! I already tested with Stephan’s code, and this issue was not fixed, I got exactly the same odd behaviour. hope your coder will have an idea! Best, Alex

• for information, my soundbridge M1001 firmware is 3.0.52 version. using nginx 1.21.4 , and if I type the modified http url in my web browser or in VLC, it works perfectly.

• I Just lost another station to HTTPs. This looks like a possible save. My entertainment system contains a Mac Mini. Could I run NGINX and the proxy server on the mini and have it proxy the Soundbridge. Both are ethernet connected and sit on the same switch.

  • Hi John, Raspberry and its codings are working under Linux. And with the appropriate knowledge (which I do not have :-), you can certainly set up a Linux partition on the Mac Mini and get the Nginx running. But with that, the task becomes more and more extensive and the further you move away from the routine I have posted, the more difficult it becomes to assign malfunctions. Accordingly, my advice would be that you also integrate a Raspberry into your network. It doesn’t cost the earth either. Best from Germany and take care of yourself. Martin

  • While I have little experience with MacOSX, I’m pretty sure this will work on the Mac Mini as well.

• Hi Martin!
  I tried installing nginx on my windows pc, and I have the same strange behaviour (already described) as using my raspberry pi under linux, I checked both can manage https url with VLC perfectly to test the reverse proxy process, but not with my M1001 , all best, Alex

  • I am planning to try using nginx, but suspect that https: is not the only problem. For some of the stations that I listen to, http: streams are available, but recently, I managed to get an http: stream for Minnesota Public Radio’s Classical channels and the M1001 will not play them, but simply putting it in my browser (Safari OS X 10.13) plays just as does the https: streams. I am wondering if something other than the transport protocol has changed.

    • Hi John, one thing you can check is if you really have the native URL of the stream you will use. I have no OS knowledge, but for my Win10 computer, I use the https://www.internetdownloadmanager.com The tool is not only for downloading media streams. With a right-click, you can see the real stream address. And this is often different from the one showing in the first level. To test if you have the right address you can use the free Apple version of the VLC-Player. Copy the URL into
      the menue “open stream” and try if it works.

    • Sorry for the confusion. I should have provided more detail. Minnesota Public Radio (MPR) sent me a list of URLs that they thought would work without https:. For example:

      http://common.publicradio.org/streams/cms.mp3.insecure.m3u

      All of these actually reference m3u playlists which the M1001 does not understand. I downloaded the playlists with wget and opened the files with emacs, my text editor. Each had content like the following 3 lines:

      #EXTM3U
      #EXTINF:-1,Classical Minnesota Public Radio
      https://cms.stream.publicradio.org/cms.mp3

      The last line is the actual stream, but note that it, too uses https. The line works in my browser and in VLC, not in the M1001. I edited the line to read

      http://cms.stream.publicradio.org/cms.mp3

      pasted it in my browser and music plays from MPR. When I paste it into VLC, music also plays from MPR, but when I paste it into one of the M1001 presets and play, I get a “Connecting to the station” message which persists forever. I would be curious to know whether using the http: version directly in your M1001 or using the https: version (or the m3u url given above) with your proxy produce a working connection.

      John

    • Like I wrote in my description of my setup, you have to modify the URL with the IP Address of the berry and – if you are using the Nginx of my coder – the slug “radio”. So if the native stream address is “http://cms.stream.publicradio.org/cms.mp3” you have to put “http://192.168.178.60/radio/cms.stream.publicradio.org/cms.mp3”
      into one of the presets. Otherwise, I think, the stream will not find the berry.

    • Hi John,

      I am the developer of the configuration presented in this article, and here comes my analysis of the problems that you reported.

      Just to avoid misunderstandings:

      http://common.publicradio.org/streams/cms.mp3.insecure.m3u
      redirects to: (*)
      https://common.publicradio.org/streams/cms.mp3.insecure.m3u
      which redirects to:
      https://streams.publicradio.org/streams/cms.mp3.m3u
      which is a “m3u” playlist file.

      So there are two tasks:

      1. follow the redirections (which the nginx-proxy does NOT)

      2. process the “m3u”-file, which the nginx-proxy does by replacing a “https”-adress with the “http://…/radio/…” address of the proxy, and then by passing it to the Soundbridge.

      Since the redirection is not treated, we should start with the actual address
      – https://streams.publicradio.org/streams/cms.mp3.m3u :

      When you replace this address with
      – http://[address-of-the-proxy]/radio/streams.publicradio.org/streams/cms.mp3.m3u
      it should return a “m3u” playlist with an already translated “http”-address :

      #EXTM3U
      #EXTINF:-1,Classical Minnesota Public Radio
      http://localhost/radio/cms.stream.publicradio.org/cms.mp3

      The Soundbridge should then be able to handle this playlist and open the “http”-address. This has worked in all cases we came across so far.

      Right now I can only test it with VLC. I will try to test it with a Soundbridge the coming week and the give you an update.

      (*) You can find out about the redirections with the command “curl -v”, e.g. “curl -v http://common.publicradio.org/streams/cms.mp3.insecure.m3u“, which among other information shows two line of interest:
      – HTTP/1.1 301 Moved Permanently
      – location: http://common.publicradio.org/streams/cms.mp3.insecure.m3u

      Best regards
      Winfried

    • Thank You Winfried
      I believe (but cannot be sure) that I unwrapped all the indirections (downloaded and examined m3u file to extract the actual (I think) stream, but additional levels of indirection could be involved.
      I also contacted Minnesota Public Radio (MPR) about the problem. They said that my problem happened at the same time that players using vTuner (vtuner.com) became unable to play MPR and thought that might be the problem. They are working with vTuner on that issue. I do not know if the M1001 uses vTuner, a service that attempts to deal with changing URLs. I am looking at dusting off some old packet capture hardware / software I have and seeing what is actually going over the wire with both the M1001 and with VLC. I have an old 100Mbps bidirectional ethernet tap I can use in the link between the M1001 and my network, but it will take a bit of effort to set up the capture.

• Also, egal, welche der Konfigurationen ich in die /etc/nginx/nginx.conf von hier reinkopiere, es scheitert immer an folgendem:
  Feb 05 12:25:11 pi4 systemd[1]: Starting A high performance web server and a reverse proxy server…
  Feb 05 12:25:11 pi4 nginx[18796]: nginx: [emerg] „server“ directive is not allowed here in /etc/nginx/nginx.conf:3
  Feb 05 12:25:11 pi4 nginx[18796]: nginx: configuration file /etc/nginx/nginx.conf test failed
  Feb 05 12:25:11 pi4 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
  Feb 05 12:25:11 pi4 systemd[1]: nginx.service: Failed with result ‚exit-code‘.
  Feb 05 12:25:11 pi4 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
  Jemand eine Idee, das wenigstens der nginx mal hochkommt …

  • NACHTRAG: Alternative Fehlermeldung
    Feb 05 12:37:30 pi4 systemd[1]: Starting A high performance web server and a reverse proxy server…
    Feb 05 12:37:30 pi4 nginx[18948]: nginx: [emerg] unknown directive „LOCATION“ in /etc/nginx/nginx.conf:1
    Feb 05 12:37:30 pi4 nginx[18948]: nginx: configuration file /etc/nginx/nginx.conf test failed
    Feb 05 12:37:30 pi4 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
    Feb 05 12:37:30 pi4 systemd[1]: nginx.service: Failed with result ‚exit-code‘.
    Feb 05 12:37:30 pi4 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
    Bevor die Frage auftaucht, ja, mit der Original nginx.conf startet der, aber egal, was ich von den ganzen Configs oben benutze, nur Fehler.

    • Bitte nicht
      /etc/nginx/nginx.conf
      sondern
      /etc/nginx/conf.d/default.conf
      anpassen.

    • Google hilft und zeigt direkt die Lösung gleich an erster Stelle an. Dein Configfile hat nicht die richtige Syntax. Hier zwei Links, die Dein Problem beschreiben
      https://stackoverflow.com/questions/41766195/nginx-emerg-server-directive-is-not-allowed-here
      https://stackoverflow.com/questions/4282146/nginx-unknown-directive-location
      Ich habe meine Roku config (siehe oben) in einer extra Datei rokuproxy (physisch in /etc/nginx/sites-available und eingeschalten per Symlink darauf in /etc/nginx/sites-enabled), welche per include in die eigentliche nginx.conf geladen wird. Deshalb fehlt bei mir oben die umschließenden http-Klammer und die events Direktive.
      /etc/nginx/sites-enabled $ ll
      insgesamt 8
      drwxr-xr-x 2 root root 4096 Jun 3 2021 .
      drwxr-xr-x 8 root root 4096 Jun 3 2021 ..
      lrwxrwxrwx 1 root root 28 Jun 3 2021 rokuproxy -> ../sites-available/rokuproxy
      /etc/nginx $ cat nginx.conf
      user www-data;
      worker_processes auto;
      pid /run/nginx.pid;
      include /etc/nginx/modules-enabled/*.conf;
      events {
      worker_connections 768;
      # multi_accept on;
      }
      http {
      ##
      # Basic Settings
      ##
      … SCHNIPP SCHNAPP …
      include /etc/nginx/conf.d/*.conf;
      include /etc/nginx/sites-enabled/*;
      }

    • Erstmal danke für eure Antworten, werde ich gleich mal ausprobieren. Allerdings wäre es ja nun schon schön, wenn man eine Dokumentation und ggf. die Konfiguration postet, so das es auch der letzte Depp (wie ich) nachvollziehen kann, ohne noch großartig googeln zu müssen, oder?

      Ich verstehe z.B. nicht, warum man die Roku-Konfiguration nicht direkt mit in die /etc/nginx/nginx.conf einfügen kann, insbesondere, wenn in den inkludierten Unterverzeichnissen

      include /etc/nginx/conf.d/*.conf;
      include /etc/nginx/sites-enabled/*;

      gar keine Dateien vorhanden sind und die dann, wenn vorhanden, ja auch nur zusätzlich eingebunden werden, warum also nicht direkt in der Hauptkonfiguration?

    • So … da in /etc/nginx/conf.d/ die Datei default.conf nicht vorhanden ist, hab ich die angelegt und eben mit dem Code IN GROSSBUCHSTABEN oben beginnend mit LOCATION da eingefügt.

      In meiner /etc/nginx/nginx.conf , die bei der Installation von nginx erzeugt/abgelegt/gespeichert wird, habe ich “Blöcke” mit “events” und “http”, in letzterem gibt es die Zeile “include /etc/nginx/conf.d/*.conf;”, was ja dann wiederum bedeutet, das die erzeugte default.conf oben “gezogen” wird … mit dem Ergebnis

      Feb 06 16:02:34 pi4 systemd[1]: Starting A high performance web server and a reverse proxy server…
      Feb 06 16:02:34 pi4 nginx[20748]: nginx: [emerg] unknown directive “LOCATION” in /etc/nginx/conf.d/default.conf:1
      Feb 06 16:02:34 pi4 nginx[20748]: nginx: configuration file /etc/nginx/nginx.conf test failed
      Feb 06 16:02:34 pi4 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
      Feb 06 16:02:34 pi4 systemd[1]: nginx.service: Failed with result ‘exit-code’.

      Der Hinweis oben bez. “googel mal” liefert ja als zweites Ergebnis genau diesen Fehler … mit der Lösung “Ensure that location directive located inside of server block” … in meiner Config da gibt es aber keinen Server-Block, wo ich das include ggf. platzieren könnte. Nun geht eben die Sucherei weiter, wie und wo füge ich nun besagten “server”-Block ein … und das ist irgendwo der Punkt, wo eben eine solche Anleitung komplett aus dem Ruder läuft und für den normal Sterblichen kaum noch realisierbar ist. Daher wäre es eigentlich prima, wenn man eben die Doku so anpasst oder schreibt, das man sie ohne weitere Fehlersuche umsetzen kann.

    • Der Serverblock ist doch genau der Config-Teil, der weiter oben gepostet wird (geht genau mit server und geschweifter Klammer los).

      Mal ein paar Worte zu Deinem Unverständnis, warum man das nicht in der nginx.conf direkt macht. Ich widerspreche hiermit auch Winfried. Das gehört nicht in die default.conf, sondern in eine site conf. Erklärung: Der Nginx ist ein Server ähnlich wie z.B. der Apache-Webserver. Hier wie dort werden verschiedene Features oder Sites so konfiguriert, dass diese in einer Extradatei stehen. I.d.R. in einer Datei unterhalb von sites-available. Man hat also einen gewissen Vorrat an verfügbaren Features, die ganz easy durch Anlegen eines Symlinks innerhalb von sites-enabled eingeschalten werden können (oder auch ausschalten, indem der Symlink gelöscht wird). Ansonsten müsste man in der Haupt-Config-Datei jedesmal den ganzen Block mit einem Editor löschen und wieder einfügen oder aus- und einkommentieren. Das ist extrem fehleranfällig und auch schlechter wartbar.

      Mein Ratschlag: Lasse die nginx.conf und die default.conf, wie sie nach der Installation war. Lege eine Datei mit beliebigen Namen in sites-available an mit dem Inhalt, welcher weiter oben steht. Danach einen symlink auf diese Datei in sites-enabled:
      cd /etc/nginx/sites-available/
      sudo nano rokuproxy.conf
      cd ../sites-enabled
      sudo ln -s ../sites-available/rokuproxy.conf ./rokuproxy.conf

    • Hi Stephan,

      ich stimme dir da grundsätzlich zu, insofern, das man den nginx ggf. für mehrere “Sachen” braucht und man ständig an der Config schraubt. In dem Fall wäre das aber nur für die Soundbridge quasi eine einmalige Konfiguration. Ich hab’s aktuell in besagtem Unterverzeichnis und der nginx startet ohne Fehlermeldung, ich kann den Radiosender (mit “manipulierter” URL natürlich) per Browser wie auch VLC streamen, jedoch nicht über die Soundbridge.

      Ich werde wohl wieder auf den MinimServer umsteigen und das über den MinimStreamer laufen lassen, das ist mir die Linzenz und die jährliche Update-Gebühr wert, zumal der mir auch gleichzeitig die Musiksammlung für die Rokus bereitstellt …

• So, nun läuft der nginx, ich kann auch den Stream über eben den nginx hören, ABER nur per Browser oder VLC, bei der Soundbridge im Abstand weniger Sekunden der übliche erneute Verbindungsaufbau …

• I have two Soundbridge M1000 devices, one Sounbridge-badged and one Pinnacle-badged. Both work(ed), have remotes, power supply. Let me know if you would like them.

• Thank you for this solution. I mostly used Stephan’s configuration. I’ve managed to bring back alive a Pinnacle (Roku) Soundbridge for my (85+) parents who didn’t have radio anymore after the cable company over here abandonned all analog radio channels. I tested everything at home before installing it at my parents house.
  I did notice a strange thing though: I added a specific hostname to the RPi so I could use that instead of an IP address which can (in theory) change and, when taking it somewhere else in another network, you wouldn’t have to change anything other than WIFI settings if you didn’t use ethernet. Using a link like for example http://webradioproxy.local:81/radio/) in a browser, works fine, but that same link in the Soundbridge presets wouldn’t connect. When using the IP address instead, everything was fine. Anyone have an idea what I’m missing here?

  • Hi Frank, I’m no network expert so please take my answer with a grain of salt.
    The Soundbridge seems to be unable to resolve the local hostname „webradioproxy.local“, because it uses a public DNS server, that knows nothing about your local hosts/hostnames.
    Is there a „DNS“ entry in the Soundbridge settings? Then you could give it the address of you local DNS server. (I assume there exists a local DNS server in your network, because your browser can resolve this address.)

• ALEX, I’ve had the same problem with the SoundBridge re-connecting repeatedly to the source and only playing a quarter-second of sound each time, then repeating the process. It’s caused by the metadata interval on the stream. Anything with metadata-interval less than 2048 will fail on the Soundbridge and cause the exact problem you described. I’m not aware of any solution other than to request the stream without the metadata. The only way I know of to do this is by using the Roku Control Protocol to request the stream without setting the remoteStream flag on the working song, as shown below (commands are case sensitive), but you won’t get any track information displayed on your SoundBridge obviously. It will connect though.
  ClearWorkingSong
  SetWorkingSongInfo title yourTitle
  SetWorkingSongInfo url yourFullUrl
  SetWorkingSongInfo format MP3
  QueueAndPlayOne working

  • Another big thanks to you Sid! I had this exact issue on my local public radio streams. My Soundbridge was behaving exactly as you described. I contacted the local station and had a great interaction with the facilities manager who actually contacted their streaming provider (streamguys) and had them change the metadata interval to 2048. My M1001 is now working with these streams again!

• thank you SID ! I downloaded the functional specification for RCP, would you give me a way to use your rcp command set to request the correct stream from roku? I guess I have to use a telnet session on port 5555 or 4444 to send these command lines

• I also have a M1000 I would like to bring back to life, but don’t have access to a Pi. I have an open media server (OMV) running and wonder if I can make this project work in a docker so I can keep the amount of things running to a minimum as well.

  • Hi Jason,

    indeed this project works like a charm in a docker container. I used a docker-compose setup when developing this solution.

    You can find this project on GitHub, with docker(-compose) files, nginx configuration, and a little readme file:
    – https://github.com/mindwork-design/soundbridge-reverse-http-proxy

    Best regards, Winfried

    • Dear M1001 Enthusiast’s,
      I’m struggling with the proxy. I set up an instance on my RPi with the /etc/nginx/default.conf out of the “https://github.com/mindwork-design/soundbridge-reverse-http-proxy”.

      This works on my “Safari”-browser but not on my Soundbridge.
      I try to play Deutschlandfunk Nova
      Link in Soundbridge: http://192.168.200.124/radio/st03.sslstream.dlf.de/dlf/03/mid/aac/stream.aac?aggregator=web

      Any idea here. Logfiles contain no useful information ;-(

      Best regards
      Erik

• Thanks for this great little project!
  A M1001 came back to life and an old Pi is the helpng hand, marvelous!
  Thanks again and all the best,
  Chris

• I recently got additional information via the Roku Community Forum (https://community.roku.com/t5/Roku-Device-Features-Settings-Updates/HTTPS-for-Roku-SoundBridge-M1001/m-p/792666#M30862). The Minnesota Public Radio URL (http://cms.stream.publicradio.org/cms.mp3) appears to be inserting song title metadata every 100 bytes or so. The M1001 cannot process this in real time and hangs in connecting / retry mode. The HTTP request issued from the presets requests the metadata (See https://cast.readme.io/docs/icy) but the M1001 can be controlled via its Roku Command Protocol input on port 5555 TCP and can be made to play this URL, RCP is described in SoundBridgeRCPSpecification2-4.pdf which is no longer on the Roku site, but a search for the title found https://github.com/noyhrynban/Roku-SoundBridge-Controller which contains the document among its files.
  If you are using the proxy, you may be able to remove the metadata request from the HTTP request for streams like this.

  • Hi John,

    from what I’ve learned from the links you provided, it is possible to persuade the server to omit the metadata by adding the http header „Icy-MetaData:0“ to each request.

    In the nginx configuration, this can be done with this directive:
    proxy_set_header Icy-MetaData „0“;

    ### 1) Configuration ###
    In order to test this, I added the following location block for a temporary location „/radioX“ in my nginx conf file („default.conf“):

    # proxy http stream, WORKS with vlc, lets the server respond without metadata in the stream
    # by setting Icy-MedaData:0
    location /radioX/publicradio {
    proxy_pass http://cms.stream.publicradio.org/cms.mp3;
    proxy_set_header Icy-MetaData „0“;
    client_max_body_size 0;
    proxy_buffering off;
    }

    ### 2) Test Results ###
    This seems to do the job; when I test it in the console with the command
    – curl -v http://localhost//radioX/publicradio > temp.mp3
    it shows the response header „icy-metaint: 0“, and in the file „temp.mp3“ there is seems to be no metadata.

    For now I could only test it with the „vlc“ program, not with the soundbridge, and it did play the stream.

    Whereas when I set „Icy-MetaData:1“ in the configuration like this:
    – proxy_set_header Icy-MetaData „1“;
    testing it again with
    – curl -v http://localhost//radioX/publicradio > temp.mp3
    it shows the response header „icy-metaint: 100“. And in the file „temp.mp3“ I could find metadata „StreamTitle: Algeria Suite“, but only once; maybe there is more metadata that I could not identify because it is encoded.

    With this configuration, testing it with the „vlc“ program it doesn’t play the radio program.

    ### 3) Summary ###
    The response headers „icy-metaint: 0“ and „icy-metaint: 100“ make me think that the server omits the metadata (when given „Icy-MetaData:0“), or inserts metadata every 100 bytes (when given „“Icy-MetaData:1“).

    Maybe you want to test it with your setup; I’d love to hear about your results.

    In any case, I will be able to test it with a soundbridge in the next few weeks.

• This is an excellent project and I’m happy to see there are still some people out there who love the Soundbridge

  Does anyone happen to have the 3.0.44 or 3.0.52 firmware file? I have a new old stock M1001 that needs an update and, of course, Roku has disabled their firmware update server for a while now. Anyone have luck on loading firmware updates on their own?

• Hi,
  habe 2 SB 1001 im Einsatz. Eine ist letztens abgerauscht und hat sich auf Werkseinstellungen zurückgesetzt. FW vers. ist version: 3.0.44 Release blackfin revision 4. Hat jemand eine Ahnung, ob es eine aktuellere Version gibt? Das Display sieht jetzt etwas anders aus als vorher. Das manuelle Firmware update auf der SB funtkioniert leider nicht, weil der update – server anscheinend nicht (mehr) gefunden wird. Ein Link auf die aktuelle FW wäre auch hilfreich, denn anscheinend kann man ein Update von einer lokalen FW – Datei über port 4444 durchführen: softwareupgrade – perform software upgrades from network or local storage.
  Wäre sehr dankbar für einen Link auf dei aktuelle FW.
  Beste Grüße

• Greetings from Dublin
  Thank you Mindwork for starting this project.
  I have 4 wired soundbridges mounted on the wall, I really like them and they have worked fine for years, both for radio and streaming from Qnap.
  Thank goodness BBC and RTE haven’t started https yet so they still work fine.
  However I wonder if anybody here had some spare time could test Newstalk radio in Dublin.http://stream.audioxi.com:8000/NT or http://stream.audioxi.com:8000/NTAAC seem to be the streams and seem to have the stuttering/ bitrate problem mentioned above.
  It would be helpful to know before I order a Raspberry Pi.
  Thanking you in advance

  • Hi Maurice,

    I will be able to test the links with a soundbridge in the next few weeks.

    Best regards
    Winfried

    • Hi WInfried, Thanks for your reply.
      Using Sid’s method above;

      telnet 192.168.0.108 5555
      ClearWorkingSong
      SetWorkingSongInfo title Newstalk
      SetWorkingSongInfo url http://stream.audioxi.com/NT
      SetWorkingSongInfo format MP3
      QueueAndPlayOne working

      I can get it to work, but if I change channel It goes back to the way it was.
      Am I doing something wrong?

• Thank you for your information regarding installing of Nginx, I had a bit of trouble running it correctly on my network for my Pinnacle Soundbridge M1001. Finally I have decided to get rid of Nginx and I´ve unplugged my Pi from network. Now I am using an old school method of adding links manually in to Soundbridge. According to my experience most of the stations Iam listening to, are running an https on theirs web sites, but directly theirs music link servers are http. So I go to my browser Mozilla Firefox, then right click on Play button of particular station on theirs web site, then I select Inspect from menu, then choose up Console and try to find and copy your station to Soundbridge, then test if it works on Soundbridge… It works for me on most of the stations. I came accross the station which Iam missing a big time without Nginx on http://listen-misoul.sharp-stream.com/462_mi_soul_128_mp3 it always change to https and my Soundbridge cannot play it without Nginx. If you know any kind of work around it will be greately appreciated.

  BTW: Sound wise I was quite satisfied with outcome from Optical Output of Soundbridge, but I have ordered cheap DAC Fosi Audio Q4 for around 40€ originally for my game console and as I had 500mA power USB adaptor from my old phone, I have decided to plug optical output from Soundbridge in to this cheap DAC and I could not believe the difference. Different instruments started to sound more naturally Piano, Saxaphone, Etc… on my Marantz amplifier. Instruments started to sound much much better compared to DAC which is built in my amplifier. Even bass do have better sound on my amplifier.

• I have two of these that I haven’t used in some years sitting in a plastic bag. They have the remotes, power adapters. I can’t bear to throw them out – they were a revelation in my music listening experience when they first came out. Free to a good home for the cost of shipping from Ottawa Canada.

  • Hello Steve, I’m in Surrey BC. and my email is sbroddy@hotmail.com. Are these M1000, M2000 or the behemoth R1000?

• Can anyone share their rpi or docker image? I’ve tried to set this up in docker on my synology but it immediately crashes on startup.

• Dear All,
  I love my Soundbridge with its very nice and retro Display. So I tried your Proxy-Idea.
  I got the nginx-Proxy working on my Raspi. I used the config file out of the Github Project (https://github.com/mindwork-design/soundbridge-reverse-http-proxy).
  This works on my laptop.
  Link stored in Soundbridge: http://192.168.200.124/radio/st02.sslstream.dlf.de/dlf/02/high/aac/stream.aac?aggregator=web
  is transferred to the proper https://st02.sslstream.dlf.de/dlf/02/high/aac/stream.aac?aggregator=web
  Same with Fritz MP3 streams. It works in Safari Browser.
  But it don’t works on my Soundbridge.

  Does anybody know why? Any tips here?

  Thanks in advance
  Erik

• Hello,
  My name is Chris and I’ve built a public version of this https to http nginx proxy for the Roku Soundbridges.
  Hopefully this will help those having a tough time building their own. Would you like to help me test?
  If you have a station using HTTPS like
  https://desertmountainbroadcasting.streamguys1.com/KBOZ-AM
  put in your preset
  http://www.opieproxy.com/roku/desertmountainbroadcasting.streamguys1.com/KBOZ-AM
  (it should only work from a Soundbridge, everyone else gets a 403 error)
  It’s my goal to bring these devices back into full functionality.
  I may have the only Soundbridge left that can browse an internet database by genre and pick a station and actually listen to it. Not just Presets. Would you like to help test that too?
  If you can redirect on your local network, the DNS entry for http://www.radioroku.com to http://www.opieproxy.com
  or add a static DNS entry for http://www.radioroku.com to 44.227.162.229
  you might be able to browse stations again.
  It’s a work in progress. „Favorites “ doesn’t work yet. But most of the „Browse“ functions do.
  If you decide to try it out, please drop me a line chris@opie.com
  and let me know how it does for you.
  Chris

• Chris,

  I have 3 of these ol‘ beasts rusting in the loft.

  I’ll be trying out your WIP as soon as I brave the inevitable spider fest up there and dig them out.

  Excuse the pun… stay tuned! meh 😉

• Hi Chris,
  I tried http://www.opieproxy.com/roku/icecast.rte.ie/radio1
  Works seamlessly

  Well done & Thank you
  Maurice

• Chris!
  What a gift to the Soundbridge legacy community!
  I tried http://www.opieproxy.com/roku/wmht.streamguys1.com/wext1
  and it works to replace https://wmht.streamguys1.com/wext1
  Thank you so much,
  Allen