softworkz 3326 Posted December 31, 2018 Share 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 Link to comment Share on other sites More sharing options...
Luke 37024 Posted December 31, 2018 Share Posted December 31, 2018 .NET Core 3.0 is scheduled for release in March. Link to comment Share on other sites More sharing options...
softworkz 3326 Posted December 31, 2018 Share 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.... Link to comment Share on other sites More sharing options...
f69m 0 Posted December 31, 2018 Share 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... Link to comment Share on other sites More sharing options...
joho500 1 Posted January 3, 2019 Share 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 Link to comment Share on other sites More sharing options...
Luke 37024 Posted January 3, 2019 Share Posted January 3, 2019 Thanks for the info. Link to comment Share on other sites More sharing options...
Luke 37024 Posted May 26, 2019 Share 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. Link to comment Share on other sites More sharing options...
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