Device is not being recognized as certified...how to fix this

I’m still unable even with the latest firmware and bridge updates to get Roon to recognised my Jr as a certified device

Very odd indeed. I also have a DSJ with all of the same firmware versions.

I had an issue a while back with roon refusing to recognize an RPi bridge if the server device was rebooted after the Pi was running, but worked properly if the RPi was rebooted with roon server running first. That turned out to be related to a firewall on the roon server machine blocking the roon bridge handshake in some way, and only from one direction (boot order dependent). Perhaps there is a firewall issue in your case as well. Do you have one running, and can it be disabled for testing?

Well one reason I hate windows, having checked all the firewall settings…seems that even having enabled all the roon settings in the firewall it still wasn’t working but turning it off seems to have fixed it after restarting the roon server.

do any of the roon public network options have to be on specifically for the DS Jr to be recognised as certified?

Windows gives me the bejeebeeze for security at the best of times…so I would like to get the firewall on again if possible

When I encountered the RPi Bridge issue mentioned in my post above (and also here Roon Bridge for ARM: a beginner’s guide to Raspberry Pi and Cubox-i), I also had all of the Roon-recommended ports allowed through my firewall (UDP 9003, TCP 9100-9200), but that was not enough. The Synology firewall had to be entirely disabled to the RPI IP address in order for Roon Bridge to connect. From this evidence combined with the OP’s issue, it looks like Roon uses more ports than I could find specified here in the forum.

@brian, can you confirm the full range of firewall ports used by Roon, including the RoonBridge service?

Thanks.

The port range that we documented long ago enables Roon Remotes to remotely control Roon Cores. It was a minor change at the time when we put it into effect, and was designed to enable a fairly narrow set of use cases where media-related devices (cores and outputs) are segregated on a separate subnet, but control points are distributed around the house on a less restrictive network.

It is not, and was never meant to be, a generic remote access or firewall hole-punching solution for all forms of communication amongst all products in Roon’s ecosystem.

RAAT/Roon Bridge use several dynamically assigned ports on each side. This protocol is designed to work on a local network without artificial obstructions. Process or host-based firewall rules are the only viable solution if you plan to place firewalls inside of your LAN.

@Paul_Chatfield to our knowledge, the Windows firewall should not interfere with Roon’s communication with Roon Ready devices or other RAAT endpoints so long as the appropriate processes are granted access to your network on the Windows machine.

Windows is supposed to show you firewall prompts for our processes the first time they start opening ports, but that stuff does not always work perfectly, and it’s easy enough to dismiss a prompt negatively and break access. Often when things are not working perfectly, you can track it down to a user-visible firewall rule that is set incorrectly.

Now that you mentioned the prompts for access I do recall there were some and they are and were all responded to allow access as requested. I can happily allow IP-IP full allow but not sure where to do that specifically in Windows as it all seems to be app name based…guess I need to brush up with Win 10

I hope to get a shot at this again but at least I am happy for now its showing up correctly and all working as spec’d.

Thanks everyone for the responses thus far 8)

Thanks Brian for the additional detail, and also the fast response on a weekend. I found a few posts from Forum moderators recommending this port range, which may have led to some confusion on my part since library discovery and endpoint discovery appear to be handled differently.

Allowing all traffic from the server machine to all of my end points has been working well for the last few weeks. I love how robust and reliable this has all been, especially the fluidity of grouping and transferring zones on the fly.

I’m having the same basic problem as Paul. Roon is saying that my Directstream / Bridge II combo is uncertified. Interestingly I have PWD / Bridge II and Roon does not display the uncertified message for it. It’s strange that Roon says one Bridge is not certified but the other one is.

The fw on both the Directstream and the Bridge II is up-to-date and I can stream to the Directstream (both my music - which resides on a Drobo 5N - and Tidal) and everything seems to work fine.

Roon resides on a Windows 10 PC. Windows firewall is off, but I use Norton and its firewall and have allowed Roon. After reading through the above comments, I turned off the Norton firewall and rebooted both the Directstream and Roon but still got the uncertified message.

With Roon streaming to the Directstream, I assume that I should just ignore the uncertified message, but things like this bug me and make me wonder if its impacting the quality of the streaming. Any suggestions?

Same here. I can stream to my DS Jr but Roon says it is uncertified.
In addition when comparing the Roon to my CD transport on the same content, I noticed intermittent clicks/pops on the Roon stream. Related?

Note: MacOS Sierra

Turn off any firewall …I had the same issue on my win10 core…turned off and bingo all good…

Edit just noted this is the same thread I started…I guess you need to double check for any other firewall type apps that might be blocking…then maybe get some core logs ready to send support perhaps

Can you post a screenshot of the screen where you see “Uncertified” showing up?

The problem appears to have solved itself. I went to get the requested screen shot, and the uncertified message was gone. Don’t know what I did as I did not turn off any firewalls. I had rebooted the Directstream a couple of times over the past few weeks for various other reasons and maybe that fixed whatever was causing the message to appear. Can’t think of anything I had done.

That CDMCM-210 string is the problem–A fully updated DSJr would identify itself as a “PS Audio DSJr DAC”, which Roon would recognize properly.

So, something has gone wrong with your firmware update on the DAC–if I recall correctly, this points towards a problem with the portion of the update that took place over USB, but PS Audio is in a better position to make the final determination.

Thanks Brian - I’ll head over to PSA and see what advice they have

I’m having the same issue. Newly installed DirectStream Junior, updated to Torreys firmware and Bridge II firmware 2.9.1. My RoonServer is a Linux NUX, everything seems to run okay, but it lists the DAC as ‘Uncertified’ and doesn’t provide any DSD options in the settings.

There are no firewall rules on the linux box…

Any additional help on this?

Thanks.

Any updates already on this?
I have exactly the same issue ;-(

I’ve just flashed my dsj again and now it’s working?!
No idea why… but I’m a bit confused since I’ve expected the support for Flac 352.8kHz which is not the case at least via roon?!