RESCUE OF A SoundBridge M1001

Roku SoundBridge M1001MIND WORK Technics SL-1300MIND WORK Technics SL-1300 Brik Stereo Moduls

But being build in 2004 the M1001 its hardware and software no longer meet today’s requirements. Because of this, there had been two major problems which I only could fix with a lot of MIND WORK.

First “bug” is the old wireless network standard Wi-Fi 802.11b of the M1001. Fortunately, the radio has a Lan-Port for 10/100mbps Ethernet. Cause of this I bought an Edimax CV-7428NS Media Bridge which can be integrated into my WiFi Mesh with IEEE 802.11b/g/n and up to 300 Mbit/s.

The CV-7428NS has five LAN-Ports to connect “non-wireless” devices to a wireless network. If the M1001 is connected via LAN and then powered up the device recognizes the connection type and boots up in LAN-Mode instead of WiFI-Mode. The installation is simple and the connection works perfectly.

MIND WORK Edimax CV-7428NS Media Bridge

The second problem can´t be fixed so easily. It has the effect that my Soundbrigde more and more is losing the ability to get in contact with radio-streams. It needs a while to identify this as a protocol issue. The Roku can work with a lot of protocols like WEP, WPA, AutoIP, DHCP, TCP, TELNET, HTTP and DRM – but not with HTTPS. And this is the point. Each time a radio station is switching from HTTP to HTTPS my ROKU is losing the capability to “receive” it. Time to put the M1001 into Garbage can? No! Time to call my friend and software developer Winfried Jacobs. I asked him for some MIND WORK to find a way for transforming HTTP into HTTPS requests. And here is what came to his mind while on a bike ride.

Raspberry Pi 1 B from 2013 with Raspberry Pi OS Lite and "Nginx" as WebserverHis solution: a Raspberry Pi 1 B from 2013 with Raspberry Pi OS Lite and “Nginx” as Webserver becoming a “Reverse HTTP Proxy” by coding the Nginx with this config:

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://localhost/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;
}

Now I just have to put “http: //192.168.178.60/radio/” in front of each of the original streaming addresses and my lovely Roku Soundbridge M1001 is unrestricted back to live. That is sustainable for me.MIND WORK Roku Soundbridge M1001 Technics SL-1300 Brik on tea tableMIND WORK Roku Soundbridge M1001 DISPLAYMIND WORK BRIK Mini Stereo Modules at vintage tea table

Vor kurzem habe ich bei eBay eine alte Roku Soundbridge M1001 gekauft. Ich mag die Klangqualität, das gerade Design, die Aluminiumoberfläche und das Old-School-Display dieses Webradios sehr. Es passt perfekt zu meinem Technics SL-1300, den Brik-Modulen und nicht zuletzt meinem aufgemotzten schwedischen vintage Tee-Tisch. Aber da das M1001 von 2005 ist, erfüllen die verwendete Hard- und Software nicht mehr heutigen Anforderungen. Hieraus resultieren zwei existenzielle Probleme, für die ich einiges an MIND WORK benötigte, um sie zu lösen.

Erster “Fehler” ist der alte WLAN-Standard Wi-Fi 802.11b des M1001. Glücklicherweise verfügt das Radio über einen Lan-Port für 10/100-Mbit/s Ethernet. Aus diesem Grund habe ich eine Edimax CV-7428NS Media Bridge gekauft, die mit IEEE 802.11b / g / n und bis zu 300 Mbit / s in mein WiFi-Netz integriert werden kann. Die Media Bridge verfügt über fünf LAN-Ports, über die “nicht drahtlose” Geräte mit einem drahtlosen Netzwerk verbunden werden können. Wenn das M1001 über LAN verbunden und dann eingeschaltet wird, erkennt es den Verbindungstyp und startet im LAN-Modus anstelle des WiFI-Modus. Die Installation ist einfach und die Verbindung funktioniert einwandfrei.

Das zweite Problem kann nicht so einfach behoben werden. Ich hatte den Effekt, dass meine Soundbrigde immer mehr die Fähigkeit verliert, mit Radiostreams in Kontakt zu treten. Es dauert eine Weile, um dies als Protokollproblem zu identifizieren. Das Roku kann mit vielen Protokollen wie WEP, WPA, AutoIP, DHCP, TCP, TELNET, HTTP und DRM arbeiten – jedoch nicht mit HTTPS. Und das ist der Punkt. Jedes Mal, wenn ein Radiosender von HTTP zu HTTPS wechselt, verliert meine ROKU die Fähigkeit, ihn zu “empfangen”. Zeit, den M1001 in den Mülleimer zu werfen? Nein! Zeit, meinen Freund und Softwareentwickler Winfried Jacobs anzurufen. Ich bat ihn, mit etwas MIND WORK einen Weg zu finden, HTTP in HTTPS-Anfragen umzuwandeln.  Und hier ist seine Lösung (danke dafür), die ihm während einer Radfahrt eingefallen ist: ein Raspberry Pi 1 B aus dem Jahr 2013 mit Raspberry Pi OS Lite und “Nginx” als Webserver, der durch Codierung des Nginx mit folgender Config zu einem “Reverse HTTP Proxy” wurde:

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://localhost/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;
}

Jetzt muss ich nur noch jeder der ursprünglichen Streaming-Adressen  “http: //192.168.178.60/radio/” vorwegstellen und meine schöne Roku Soundbridge M1001 ist wieder uneingeschränkt verfügbar.  Das nenne ich nachhaltig.:)

28 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.

    Liked by 1 person

    • 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.

      Like

  • 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.

    Liked by 1 person

  • 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.

    Like

    • 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

      Like

  • 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

    Like

    • 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

      Like

      • 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

        Like

  • 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?

    Like

    • 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

      Like

      • 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

        Like

  • 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

    Like

  • 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 !

    Like

    • 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

      Like

  • 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

    Like

  • 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;
    }
    }
    }

    Like

  • 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.

    Like

  • 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

    Like

  • 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.

    Like

  • 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.

    Like

    • 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

      Like

  • 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

    Like

    • 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.

      Like

      • 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.

        Like

      • 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
        [audio src="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

        [audio src="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

      • 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.

        Like

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: