anderbytes 139 Posted July 18, 2016 Author Share Posted July 18, 2016 Any indication what the code changes are...? Happy to try dev or beta when I next have a free few hours I have looked at it very quickly (busy here), but so far I've seen some connections that weren't asynchronous, and they were fixed to be that way. Link to comment Share on other sites More sharing options...
Luke 37060 Posted July 23, 2016 Share Posted July 23, 2016 There's a new stable up, 3.0.6000, it contains the changes I made. Thanks. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted July 24, 2016 Author Share Posted July 24, 2016 There's a new stable up, 3.0.6000, it contains the changes I made. Thanks. I'll be installing it outside Docker to test it correctly, later today. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted July 24, 2016 Author Share Posted July 24, 2016 (edited) There's a new stable up, 3.0.6000, it contains the changes I made. Thanks. Luke, I'm sorry, I still can reproduce the issue. I'm giving up. Docker it is. Edited July 24, 2016 by anderbytes Link to comment Share on other sites More sharing options...
Luke 37060 Posted July 24, 2016 Share Posted July 24, 2016 Ok, I can't reproduce it. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted July 24, 2016 Author Share Posted July 24, 2016 (edited) If anyone wants to continue from here. That's what I got: REQUIREMENTS TO MY SCENARIO: - Linux system (mine is Debian 7) - Emby installed in main system (not something as LXC or Docker) - Only HTTPS port Forwarded in Router. - Android Client STEP-BY-STEP: - In Server Linux Shell, run the following command: watch -n 1 -d "ss -anoe | grep 8920 | grep -v LISTEN" <-- That helps monitoring the ports opened by 8920 - Connect to Emby server in your Android Client - Wait for some connections to appear at Watch screen above (5 or more) - Suddenly disconnect Android from his network (disable Wifi or disable Data). Leave disconnected. - Look the opened ports inside Watch above - Wait 5+ minutes. Look at the ports. - Most of ports fade out by their own. - One doesn't. Stays this way. Godbye topic Edited July 24, 2016 by anderbytes Link to comment Share on other sites More sharing options...
Luke 37060 Posted July 24, 2016 Share Posted July 24, 2016 Ok, so this is only affecting the https port. Good info, thanks. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted August 29, 2016 Share Posted August 29, 2016 (edited) Okay so issue still present in latest debian server This time it was using the web client from a remote location. I found that if I paused the film, it would jump back in time massively or even start from the beginning (not sure if related?) It seems though that other previously connected remote clients still work though after the web interface becomes inactive. Signing on locally to the dashboard via a VPN to the non https address shows tv series still playing on a different remote connection. After it stopped working for me, netstat full of CLOSE_WAIT connections. Would the pausing / skipping a film cause new connections? root@server:/ # netstat -anoe | grep ":8" tcp 0 0 0.0.0.0:8920 0.0.0.0:* LISTEN 109 990711 off (0.00/0/0) tcp 0 0 0.0.0.0:8096 0.0.0.0:* LISTEN 109 990709 off (0.00/0/0) tcp 0 0 192.168.1.5:8096 10.0.5.14:5117 ESTABLISHED 109 1252995 off (0.00/0/0) tcp 0 0 192.168.1.5:8920 176.249.21.199:61100 ESTABLISHED 109 1246106 off (0.00/0/0) tcp 192 0 192.168.1.5:8920 82.0.219.130:5100 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 0 0 192.168.1.5:8920 176.249.21.199:62266 ESTABLISHED 109 1252782 off (0.00/0/0) tcp 192 0 192.168.1.5:8920 82.0.219.130:5101 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 192 0 192.168.1.5:8920 82.0.219.130:5098 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 192 0 192.168.1.5:8920 82.0.219.130:5102 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 192 0 192.168.1.5:8920 82.0.219.130:5099 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 0 0 192.168.1.5:8096 10.0.5.14:4540 ESTABLISHED 109 1250967 off (0.00/0/0) tcp 0 272719 192.168.1.5:8920 176.249.21.199:61234 ESTABLISHED 109 1246191 unkn-4 (4.46/0/0) tcp 192 0 192.168.1.5:8920 82.0.219.130:5103 CLOSE_WAIT 0 0 off (0.00/0/0) Edited August 29, 2016 by spudy12 Link to comment Share on other sites More sharing options...
Luke 37060 Posted August 29, 2016 Share Posted August 29, 2016 Try it without a vpn or proxy. i have measured this with recent server releases on ubuntu and cannot reproduce it. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted August 29, 2016 Share Posted August 29, 2016 REQUIREMENTS TO MY SCENARIO: - Linux system (mine is Debian 8.5) - Emby installed in VM running on a proxmox server. Network access NAT'd so looks like local device - Only HTTPS port Forwarded in Router. - Android Client and web client Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted August 29, 2016 Share Posted August 29, 2016 (edited) Try it without a vpn or proxy. i have measured this with recent server releases on ubuntu and cannot reproduce it. Luke, VPN was only used to connect to network with the server on AFTER the problem had occurred to troubleshoot etc. Normal https port was used prior to it becoming inaccessible. Edited August 29, 2016 by spudy12 Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 29, 2016 Author Share Posted August 29, 2016 REQUIREMENTS TO MY SCENARIO: - Linux system (mine is Debian 8.5) - Emby installed in VM running on a proxmox server. Network access NAT'd so looks like local device - Only HTTPS port Forwarded in Router. - Android Client and web client I guess you can remove that second requirement. I had Emby installed in a common server, and the problem existed. After migrating to Docker... never saw the issue again. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted August 29, 2016 Share Posted August 29, 2016 What network card where you using? Did you follow any good guides to setup docker? I might have to migrate if I can't get this fixed. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 29, 2016 Author Share Posted August 29, 2016 What network card where you using? Did you follow any good guides to setup docker? I might have to migrate if I can't get this fixed. I'm using a integrated Realtek network card from Mobo Gigabyte GA-H81M-DS2V. To setup docker I was lucky that OMV (my NAS solution) has a plugin to install and manage it. Link to comment Share on other sites More sharing options...
monotok 7 Posted September 28, 2016 Share Posted September 28, 2016 (edited) Hello All, I thought I would add my experience with this too. I decided to subscribe to the premiere so I could properly test emby. Unfortunately I have started having this issue. I am unable to connect to the HTTPS port on 8443 after a couple of days but the HTTP web page works fine. This is running: Ubuntu 16.04 in a VM on ESXi 6 with 6 GB of RAM and 4 CPU's. Emby version 3.0.7200.0 I do use the Android client however I noticed a huge number of connections using NETSTAT from my main Laptop (Arch Linux). I tried closing the browser but the connections seemed stuck. I had to reboot the emby service for the connections to disappear and I could once again connect via HTTPS. Just done a quick test and I can confirm that both the laptop & android client connections via HTTPS closed after 5 minutes or so. So this still occurs under some scenarios but hard to pinpoint. My laptop is .1 and I left the HTTPS web page open with the laptop running most of the time. I will try keeping the tab closed and see if that makes a difference. If this still occurs then I will give it ago on FreeBSD; has anyone had any issues on FreeBSD? I started using it for a backup VM so don't mind using FreeBSD. tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 121 70440 off (0.00/0/0) tcp 201 0 172.16.20.11:8443 172.16.20.12:41194 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:41982 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:33734 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:58608 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:51532 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:42610 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 178.62.193.70:38970 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:42868 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:37594 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:60160 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 231 0 172.16.20.11:8443 31.55.43.148:48265 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 231 0 172.16.20.11:8443 31.55.43.148:59013 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.97.58:44545 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:33474 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:39562 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 0 0 172.16.20.11:8443 149.254.57.39:41910 SYN_RECV 121 0 on (11.64/4/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:45332 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:60710 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:47930 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:43424 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:52688 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 230 0 172.16.20.11:8443 31.55.43.148:38533 ESTABLISHED 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:36082 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:36340 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:57848 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:49718 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:35696 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:40206 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:41852 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:52302 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 200 0 172.16.20.11:8443 172.16.20.12:41191 ESTABLISHED 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:38102 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:50886 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:45850 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:48316 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:56578 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:52178 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:34240 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:58492 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:39654 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:55006 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:57230 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:56294 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:58866 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:53616 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.170.67:10178 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:39304 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:60060 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 0 0 172.16.20.11:8443 86.187.97.58:39829 ESTABLISHED 121 254451 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:44714 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:38360 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.97.58:39163 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:57488 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:54746 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:55650 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:47672 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:32828 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:40814 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:56838 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.170.67:9920 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:35436 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:33086 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:38240 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:52044 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:55392 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:44428 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:47026 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:47284 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:58750 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:59902 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:38748 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:57200 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:48294 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:59254 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:44456 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:40554 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:37982 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:39006 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:36730 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:35148 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:48938 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:34122 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:59512 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:40852 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 231 0 172.16.20.11:8443 31.55.43.148:55842 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:39396 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.97.58:43503 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:56192 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:55932 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:41464 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:34380 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:42222 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:49160 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 231 0 172.16.20.11:8443 31.55.43.148:45643 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:56036 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.97.58:41962 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:43164 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:49458 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:41204 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:33122 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:45074 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:48552 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 179 0 172.16.20.11:8443 86.187.97.58:41051 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:41962 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:34500 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:40592 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:54866 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:43810 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:45720 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:37336 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:34886 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:53358 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:48574 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:57460 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:44686 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:36988 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:52436 CLOSE_WAIT 0 0 off (0.00/0/0) tcp 196 0 172.16.20.11:8443 172.16.20.1:52968 CLOSE_WAIT 0 0 off (0.00/0/0) Edited September 28, 2016 by monotok 1 Link to comment Share on other sites More sharing options...
sv3nno 2 Posted November 23, 2016 Share Posted November 23, 2016 I'm having the exact same problem as monotok, a load of connections in the CLOSE_WAIT state. No new HTTPS connections could be made. Have clients across the internet, so HTTP is not an option. Currently need to restart the emby service 1-2 times a day. Running Ubuntu 16.04 as guest on VMware ESXi 6.0.0. Emby server version 3.0.8500.0. 1 Link to comment Share on other sites More sharing options...
anderbytes 139 Posted November 23, 2016 Author Share Posted November 23, 2016 I followed this thread for a longe time... at the end, it's probably something related to Mono and HTTPS, I guess. If the dev team had some Linux freak with Mono knowledge, probably this issue wouldn't live for so long. Link to comment Share on other sites More sharing options...
Luke 37060 Posted November 23, 2016 Share Posted November 23, 2016 We do, but sometimes we have to wait for upstream issues to resolve themselves. Mono itself has different implementations depending on what platform it's running on and this is a big part of the reason for this varying from one OS to another. Link to comment Share on other sites More sharing options...
Luke 37060 Posted November 23, 2016 Share Posted November 23, 2016 You guys should all try this out to have a little fun: https://emby.media/community/index.php?/topic/41636-emby-server-running-under-net-core/ 1 Link to comment Share on other sites More sharing options...
sv3nno 2 Posted November 23, 2016 Share Posted November 23, 2016 I see. I was wondering about using nginx as reverse proxy, would this eliminate this problem with stale connections? Anyone have experience with this? Could be good to have security-wise aswell. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted November 23, 2016 Share Posted November 23, 2016 That should solve the issue if SSL is terminated with nginx and will allow some other nifty tricks. Apart from that it won't really provide any security benefits. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted November 23, 2016 Share Posted November 23, 2016 You guys should all try this out to have a little fun: https://emby.media/community/index.php?/topic/41636-emby-server-running-under-net-core/ This looks very promising @@Luke Will keep my eye on this and test it when I get some free time! Link to comment Share on other sites More sharing options...
anderbytes 139 Posted November 24, 2016 Author Share Posted November 24, 2016 You guys should all try this out to have a little fun: https://emby.media/community/index.php?/topic/41636-emby-server-running-under-net-core/ I'm running the official Emby image for Docker... but I guess I can manually do this (every time an image is downloaded :-( ) Hope it makes Mono obsolete! Link to comment Share on other sites More sharing options...
Luke 37060 Posted November 24, 2016 Share Posted November 24, 2016 I'm running the official Emby image for Docker... but I guess I can manually do this (every time an image is downloaded :-( ) Hope it makes Mono obsolete! There are Docker instructions: https://www.microsoft.com/net/core#windowsvs2015 Link to comment Share on other sites More sharing options...
anderbytes 139 Posted November 24, 2016 Author Share Posted November 24, 2016 There are Docker instructions: https://www.microsoft.com/net/core#windowsvs2015 Cool... but nothing like an official image with Dotnet and Emby already installed and ready to go, right? :-) Maybe with another tag "beta_netcore"... I don't have much time now to manually setup the dotnet environment... but I'll probably do it eventually, if no image is made for that. 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