I just got the Merging Technologies hotline this morning and they allowed me to reinstall the Merging Audio Device (Merging RAVENNA/AES67 Vitual Audio Device Installer - 3.2.0 build 50895).
Many thanks to them!
This driver works correctly again on my PC, even if officially this one is not compatible with Windows 11.
On the other hand, software like Pyramix or Pro Tools does not yet work on Windows 11.
So I came back to the same starting point of the beginning of last week.
Roon’s log files reporting the same malfunctions.
You are right, although I find the members of the forum very sympathetic and undoubtedly competent on computer subjects in general, I will wait for Roon Support team to come back to me.
I continued to persevere in my attempts to install Roon.
And after the xth time, after having uninstalled then reinstalled the Windows 11 updates (is it the “Cargo Cult” ???) the installation was finally possible.
For all practical purposes I keep the Roon log files before (certifying that Roon does not work) and after (conclusive installation) in case the Roon Support team is interested in this scenario. @Geoff_Coupe Tell me, Geoff.
Last night after using Roon all day I restarted my PC (around 10:00 p.m. Paris time) to check that everything was in order and again Roon did not restart anymore.
When I woke up this morning, I still had the Roon splash screen.
Of course, I have all the log files from yesterday and this morning.
@Geoff_Coupe@Rugby@Beka This time I am waiting for help from Roon Support regarding the analysis of these log files and a solution to be able to use Roon again.
@Geoff_Coupe Also please reactivate this thread which should be closed within two days.
Thanks for your patience here while @beka flagged me and for the other users chiming in with some very helpful suggestions so far!
I do recall a few similar cases with these error messages. Some of the time this was triggered by Windows updates, but for other users it was due to a program called Wifi + Transfer:
Do you by any chance have this app? It might be interfering with Roon starting due to this port conflict. If you don’t have this app, then I’d advise running Windows Advanced Port Scanner and see if another program is using port 1900:
Also, while this doesn’t help your case at the present moment, I do want to mention that we are investigating this type of hang on the QA side to see what improvements we can make in this area.
Thank you very much, Noris.
Now my problem is solved.
Just before you sent this message, there may have been thought transmission , I had just found the thread in which the problem of WiFi+ Transfer was mentioned and it was precisely the cause of Roon not working for me.
All this made me have a bad week all the same.
Glad to hear that it helped solve the issue, @Stephane ! I am curious as to why the issue just started following the Windows Update (assuming you had WiFi + Transfer installed before) but I’m hoping the rest of your week will be better with some music
Nothing to do with the Windows updates, it’s just what I thought while fearing the Cargo Cult effect, and it was.
I indeed very recently installed a software called Nero to make a CD copy for one of my friends and this Nero software also installed this WiFi+ Transfer which started when Windows starts.
Maybe when I just uninstalled the Windows updates, this disabled the start of the software WiFi+ Transfer, but as soon as I restart Windows, then WiFi+ Transfert started again.
Sorry for my poor English especially since it’s 2:09 am here in Paris
(It was a train that took me away from here...)
Man that’s a nasty chain of events, glad you got it sorted @Stephane
Here it seems that the other software at Windows startup binds to its preferred port 1900, which is also used by Roon, which then throws an exception and hangs when the user tries to start the application.
As @Stephane was able at one time to start Roon after several reinstallation attempts, it seems as if the other software had some kind of fail-over mechanism and can bind to an alternative port, if at startup it finds it can’t connect to port 1900.
Roon could implement a similar fail-over mechanism and so prevent this thing from happening again. This would also take care of other software products possibly out there which use port 1900.
This post is about the port range used for the extension API. This has nothing to do with the problem experienced by the OP.
This was the problem:
04/22 15:15:07 Warn: [multicastreceiver] couldn’t bind to iface 169.254.187.211:1900, message: Une tentative d’accès à un socket de manière interdite par ses autorisations d’accès a été tentée
04/22 15:15:07 Warn: [multicastreceiver] couldn’t bind to iface 192.168.1.21:1900, message: Une tentative d’accès à un socket de manière interdite par ses autorisations d’accès a été tentée
04/22 15:15:07 Warn: [multicastreceiver] couldn’t bind to iface 127.0.0.1:1900, message: Une tentative d’accès à un socket de manière interdite par ses autorisations d’accès a été tentée
It is now clear that a third-party software has already bound to port 1900, so Roon’s ‘multicast receiver’ failed.
Edit: In fact this is a little more intricate… at the moment when ‘multicast receiver’ tries to bind to port 1900 of all identified network interfaces, Roon doesn’t fail. Notice that in the log it shows a warning, not an error. It fails some time later, when Roon tries to open a socket connection on the interfaces. Then it throws an exception and logs an error, because before opening a socket connection it must have bound to the respective network interface.
So ‘multicast receiver’ could bind to another fail-over port, when it finds that it cannot bind to port 1900. And, of course, the code which is executed later at the moment of establishing the socket connection must then be notified that it cannot open the connection on port 1900 but on fail-over port…