softworkz 4569 Posted December 31, 2018 Posted December 31, 2018 (edited) Having the same problem here. EmbyServer tries to open UDP port 1900 for SSDP exclusively, which is a bad idea. When I start EmbyServer first, it works fine, but several other applications then fail to open port 1900. If one of the other applications is started first, other applications can share port 1900 fine, but I get the described error from EmbyServer. SSDP is often used by multiple processes for service discovery like DLNA and (at least on Linux) should be opened with the SO_REUSEADDR socket option set. EmbyServer sets SO_REUSEPORT (twice), but not SO_REUSEADDR. Some quick tests with Python show that Linux requires SO_REUSEADDR to be set for sharing multicast UDP ports, SO_REUSEPORT does not work. @@f69m - your findings are correct in every detail except one: It's the .net core Linux runtime that is doing wrong, while Emby is correctly requesting SO_REUSEADDR. We've not only narrowed down the cause, we know precisely why it happens down to the Unix native .net core runtime implementation . This is from an internal mail on this subject: The problem was introduced with .net core 2.1. It had worked fine with previous versions: Reported here for example: https://github.com/dotnet/corefx/issues/32027 This is the commit that screwed things for .net core 2.1: https://github.com/dotnet/corefx/commit/7eba4bf88983ac276348ea1626c81595e1b237c6#diff-3c0edd8d16aa366989215dba11a0bc08 Unfortunately it has not yet been resolved in .net core 2.2: https://github.com/dotnet/corefx/blob/release/2.2/src/Native/Unix/System.Native/pal_networking.c This is the PR that has been merged and will fix the behavior for .net core 3.0: https://github.com/dotnet/corefx/pull/32046/files Conclusion Until .net core 3.0, there's nothing we can do, I think. (except some crazy stuff maybe, but that would need quite a bit time to work on) Edited December 31, 2018 by softworkz
Luke 40087 Posted December 31, 2018 Posted December 31, 2018 .NET Core 3.0 is scheduled for release in March.
softworkz 4569 Posted December 31, 2018 Posted December 31, 2018 I think, this is something we can (and should) wait for. Before someone might ask what I meant by 'crazy things' - that would have been either: Backport the fix to .net core 2.2, then compile and distribute a custom version of the .net core 2.2 runtime for Linux...or... Try to p/invoke some native calls to set the required socket option Both variants are easily written down but horrible to accomplish. So let it be those 2-3 months....
f69m 0 Posted December 31, 2018 Posted December 31, 2018 Thanks for the quick response and for all the details. Yeah, the breaking change was for TCP, where using SO_REUSEPORT makes sense, but it is different for UDP. Oh well, lets wait for 3.0...
joho500 1 Posted January 3, 2019 Posted January 3, 2019 I am using BubbleUpnpServer on Linux and found out that making a proxy for Emby Server is working to make Emby Server available as dlna server despite it currently not working on its own. FYI Cheers, Joost
Luke 40087 Posted May 26, 2019 Posted May 26, 2019 This exception should be resolved in the Emby Server 4.2 beta builds if you guys would like to try that. Thanks.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now