Roon no longer starts after 10 days of non-use [Solved - Port issue due to WiFi + Transfer program]

Thank you Geof @Geoff_Coupe for all these explanations and insights. In Windows 11 odyssey

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.

@Roger_Staines I will finally be able to go on vacation again. :sunglasses:

Thanks again everyone.

This incident can be closed.


Stephane I’m very happy for you that you will have music again with Roon.
Did you find out what the cause was though, just in case it happens again? :scream:

Unfortunately, the joy was short-lived…

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.

1 Like

I tried to install Roon 1.8 (build 933) and then Roon 1.8 (build 935).
No change. The problem remains the same.

@beka @support
I am still waiting for help from Roon Support regarding the analysis of these log files and a solution to be able to use Roon again.
I can of course send you my latest log files.

Hi @Stephane ,

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. :+1:
Now my problem is solved.
Just before you sent this message, there may have been thought transmission :wink:, 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 :headphones:

1 Like

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

Sorry for my poor English especially since it’s 2:09 am here in Paris :laughing:


Man that’s a nasty chain of events, glad you got it sorted @Stephane

1 Like

It would be great to have a thread or Wiki page or something that listed these kinds of things – the symptoms and their causes – instead of having to re-find them every time.


Agree totally about the Wiki, but documentation efforts are always left to the weak sister.

I imagine there’s a Knowledge Base editor somewhere reading these posts.

The goal here is not to document these kinds of issues, but to fix them outright. As I mentioned earlier in the thread:

But meanwhile… Though, if it’s some other software causing the problem, I don’t really see how you can “fix it outright”.

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.

As for ports, please see this post

Yes, in this particular case. But not in general.

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


This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.