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.:)

49 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

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

      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

      • 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://%5Baddress-of-the-proxy%5D/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
        [audio src="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

        Like

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

        Like

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

    Like

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

      Like

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

        Like

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

        Like

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

        Like

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

        Like

      • 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

        Like

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

        Like

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

    Like

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

    Like

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

    Like

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

      Like

  • 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

    Like

  • 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

    Like

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

    Like

  • 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

    Like

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

    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 )

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: