Many thanks to SWLing Post contributor, Rob Gray, who recently reached out with some potentially concerning information about Reciva radios.
Evidently, some users are claiming that Reciva chips require a periodic token refresh to keep the radio functioning properly.
Rob writes:
From this internet radio forum a contributor wrote:
“Apparently, even stations with URLs stored locally on the radios as presets, will eventually stop working. The Reciva chips require a token to be renewed periodically from the Reciva server; once the server is turned off, the token can no longer be renewed, and the radio becomes a dead parrot. Apparently Reciva did this to prevent their chips from being pirated.”
Another contributor wrote:
“….when I asked Grace about it, their reply was that while the presets would work for a time, eventually even that function won’t work because the radios require a token to be renewed periodically from a Reciva server. If the server is gone and the token can’t be renewed, the radio becomes a doorstop. It wasn’t clear how long the radio will work…”
I don’t know if this is true or not (time will quickly show), but when I asked C.Crane about this a while back, they seemed aware of the possibility and their experts gave it a 50/50% chance of success/failure based on tokens.
Speaking with a very knowledgeable friend on the topic, he has described that the real, ultimate way to tackle this problem is to have a ‘packet sniffer’ and monitor all the traffic in/out of the network to understand what data is being used (like if there is a token for example) and reverse engineer what Reciva is doing.
Thank you for bringing this to my attention, Rob.
Tokens: Can someone prove or disprove this?
There are some savvy programmers, network specialists, developers, and hackers in the SWLing Post community. My hope is that someone can use a packet sniffer or similar device to determine if this is true or not. Since the Reciva service will close down by the end of the month, time is of the essence.
My hope is that if there is a token, it won’t shut down functionality to a point that we can’t stream from our own IIS or perhaps the token can be reverse-engineered. Or maybe there is no token at all, or if there is it will have no impact on usability after the Reciva service has closed.
Please comment and/or reach out to me with any evidence. I’d like to clear this up with some facts. Many thanks in advance!
anyone have a straightforward procedure to retireve the stored stream url’s on the GDI-IRC6000 memory locations? thx
Earlier this year I bought two Grace Mondo Elite radios to replace my My C-Crane WiFi radio (ethernet model); however I can report that my C.Crane radios are still working. (Meanwhile, Grace doesn’t seem to be offering much anymore which makes me nervous that their service will go under next.)
On the C.Crane WiFi radio I only make use of the presets so I doubt I could change those with Reciva shut down but what I have is still working. Anybody have any idea how long they’ll keep working? Did anybody ever confirm if there is a token? (And to respond to TC’s comment, I think they used http, not https, which makes me wonder if that didn’t have something with shutting down the service since http is no longer supported.)
Personally, I’m not a fan of replacing WiFi radios with bluetooth speakers, smartphones and the like. Bluetooth is okay in a pinch but I dislike the periodic re-pairing of devices, dropped connections if the devices are too far away, etc. (I’d rather read on my Samsung and iPad tablet than listen to anything through the tinny speakers.) I prefer the simplicity of a radio format. As a result, I would be disappointed to see the WiFi radio market disappear.
Does anybody here have experience with the latest C.Crane WiFi radio? I would have sprung for the replacement model with C.Crane vs. Grace but I was told — before it came out — that there would be no way to run it off of Ethernet, even by USB adapter, so that was a deal breaker.
At any rate, I’d be curious to know how many people have bricked Reciva radios vs. still operating?
It is now 12/5/2021.
My Grace Digital IRC6000 “mondo” can’t find the mothership Reciva.com.
I can navigate some basic screen functions but that’s it. No stations.
Replaced the CMOS battery so now at least the clock works.
Any idea if we can fake this radio out with another mothership?
Help
Bill
One thing that has gone under the radar here is that several Grace Radio models, in addition to being impacted by the Receva shutdown, can’t stream SiriusXM as of March 31st.
Grace Radio posted an announcement about this here:
https://support.gracedigital.com/hc/en-us/articles/360045179733–SiriusXM-Service-update-
I was hoping that SiriusXM would still work on my model – it’s the only component style Internet radio (GDI-IRDT200) that Grace made that fits in my audio system rack and I’ve used it a lot to listen to SiriusXM’s streaming service. But, it looks like it’s a brick now.
Curious, anyone opened an affected radio to look for possible jtag or serial headers to maybe get at the firmware?
my advice is to get someone to build this for you 🙂 https://www.instructables.com/Raspberry-Pi-powered-Internet-Radio/ (or build it yourself , looks easy!
Well, after 3 hours of being bricked, the radio is now playing. Internet connection was never the problem here.
I hope it’s just mine for everyone’s sake, but the end remains ahead unless some of the genuises solve it for us. Really hoping so.
Radio still bricked here.
Fired my thumbs for the typo…Geniuses
If the comment below is mistaken and the radios are still working, there is an easier way to test the token theory. Simply block the Reciva-specific addresses which the radios contact, simulating what it would be like for those servers to go down. If the presets break, a token is required. This wouldn’t disprove a token which lasts a month or more; sadly it’s too late to disprove that, but it does give us a yes or no.
If there is a token, things may be tricky. It’s always possible that someone watching the packet stream can reverse-engineer the protocol in use, but if they’ve bothered to make a token system for piracy prevention, they already anticipate reverse engineering so it’s likely protected in such a way where it’s not simple to use it. I suppose we could track down the former operators and see if they’re willing to give us any technical documentation they may have, as it’s no longer any use to them. Still, that’s an hour of a developer’s time and they probably won’t be willing.
This is why I won’t buy a WiFi radio and I recommend you don’t either. Unless there is an option to provide local station information, it can be turned into a paperweight at any time, from a provider shutting down to a server malfunction. Even those which do have local preset functions are pretty limited, as you have to maintain the stream data yourself. Given the number of portable devices which can be reprogrammed easily, I advise against the purchase.
Well April Fools are us, as it appears they bricked the radios today. My WFR28 is just permanently connecting. Removed power to reset and it took about 10 minutes for the clock to sync…not just connecting for last hour. Seems to have happen at 1700EDT.
I think all the recent problems with standalone wifi radios demonstrate that they are more trouble than they’re worth. The aggregator sites go out of business, or they have other software problems.
There are better options to tune in to internet radio: smart speakers, laptop/desktop computers, smart phones. Don’t waste your money on wifi radios. A good idea at the time; not any more.
I personally love the idea of standalone Internet radios, and there is still a lot of good content to listen to, but I’ve reluctantly come to agree with this assessment.
One way around the situation (aside from just using your cell phone) is to home-brew a standalone Internet radio using a Raspberry Pi or similar microcontroller. This is obviously only for the technically inclined, but there are some options out there.
I have a roughly 90% done standalone WiFi radio built into the shell of a defunct 1940s AM receiver, using Bob Rathbone’s Raspberry Pi setup. It can be tuned using front-panel controls, or an Android app (it uses the MPD protocol).
I also have a CCrane WiFi 2 — which I bought second-hand — recently, unfortunately, but for a low price. I was tempted to take advantage of CCrane’s upgrade offer, but in the end felt it wasn’t worth “throwing good money after bad”. After it’s bricked, I may repurpose the chassis and as much of the internals as I can, for some other project.
I agree – it would be pretty straightforward to sniff the packets with the correct network setup, although the radio possibly uses https for its connections, which could complicate things.
I’d try it myself, but I don’t have one of these radios!