The SoundBridge M1001 has a lot of protocols the device can work with. But being 15 years old, HTTPS is not implemented. So the radio is dying in slow motion - each time a station is changing from HTTP to HTTPS it passed away for owners of a SoundBridge. Until now. Cause I love my M1001 I made a workaround. So have a look at
Best from Cologne and take care
M.
I am considering using the proxy mentioned in the previous message as a solution for my M1001 connectivity issues, but I wonder if there is any possibility of ROKU releasing the source for the latest version of the M1001 firmware so that the community could make the updates necessary to keep the devices going. If anyone from ROKU watches this list, a reply or point of contact would be appreciated.
I recently lost access to Minnesota Public Radio's Classical channels when the rearranged their streaming URLs. After corresponding with MPR and dissecting their latest URLs (mostly m3u playlists with embedded streams), I found that the URL will play the channel in the VLC player (and the Safari bowser on my Macs), but causes the M1001 to hang in the "Connecting to station" state. This makes me suspect that there may be additional problems with the streams that are giving the M1001 trouble.
I had a look at the stream you posted, and the metadata interval is set to 100 bytes. That basically means the server is inserting the track title into the mp3 stream roughly every 1/100th of a second, bizarrely, and the Soundbridge is trying to strip out that data in real time, which is way beyond it's performance capability. In my experience the SoundBridge will handle a metadata interval of 2048 or higher, but fails on streams with shorter intervals. Sometimes stations have alternative streams with different metadata intervals, but finding them is difficult. The only other solution is to use the Roku Control Protocol to request the stream without the metadata. Unfortunately there's no way to do that using the remote control presets. You have to either do it programmatically or send the commands to the Soundbridge via a telnet connection to it on port 5555. I can't remember how to connect via telnet (it's in the RCPspecification document) but the case-sensitive commands you'll need to connect to the stream are:-
ClearWorkingSong
SetWorkingSongInfo title CMS
SetWorkingSongInfo url
SetWorkingSongInfo format MP3
QueueAndPlayOne working
Thank you for the information. I have passed your observation of the short metadata interval on to the people at Minnesota Public Radio. Meanwhile, could you point me to a source of the RCP Specification Document you mention. Also, could you describe the method you used to look at the stream. I would like to try it on several other problematic streams.
Unfortunately Roku seem to have removed the document soundbridgeRCPspecification2-4.pdf from their site. If you have the CD that came with your Soundbridge you'll find it on there. I'd attach the file here but there's no attachment facility.
I used my own code project to view the HTTP response headers from streams. There might be a way to do it in Chrome devtools but you need to be able to customise the HTTP request header to request the metadata (Icy-Metadata: 1). Opening the site in Chrome won't do that by default, so looking at the response header in the Devtools Network tab won't show the icy-metaint value which is what you need to see. When the Soundbridge connects to a radio server it connects to the host on port 80 and then sends a HTTP header in this format:-
GET /filename.mp3 HTTP/1.0"
User-Agent: Roku SoundBridge/3.0
Host: yourexample.com
Accept: */*
Pragma: no-cache
Icy-Metadata: 1
Thanks again. A web search for the pdf document you reference (soundbridgeRCPspecification2-4.pdf) turned up a project on github that has a copy of the document among its files. This should be sufficient to get me going.
Thanks for the github link to the Mac OS X App to control the Roku Soundbridge. I'd really like to keep my M2000 and M1000 going. At one point there was an iOS app to control the Soundbridge, but it never made it past the 64-bit transition. It would be a cool little project to create a new iOS controller.
Thee Soundbridge does have an embedded web server but it's extremely limited for controlling the device. And since it's only reachable through HTTP, and some browsers are phasing out non-HTTPS URLs, it becomes an issue even on a local network.
Getting off-topic now, but searching around for old Soundbridge archives, I found a 3D printer model for the Soundbridge endcaps. All of mine broke probably over a decade ago.
I've setup a public proxy for this if anyone is interested.
If you have a station using HTTPS like
put in your preset
(it should only work from a SoundBridge, everyone else gets a 403 error)
I've tested it on firmware versions 2.7.38, 3.0.44, and 3.0.52
R1000's, M1001's and newer M1000's
I don't have M500's, older M1000's or M2000's to test with.
I'm also working on bringing back the Internet Database of stations functionality.
If anyone is interested in testing that with me let me know.
You must be on 3.0.44 or higher.
Chris