Emby stops responding to https every couple days

[Carlo 4560]

Couple questions for you guys.

1. This only happens for https correct?

2. When you can't connect over https can you still access Emby over http?

3. Do any of you guys have IP6 bound?

4A. Is anyone NOT using a cert but just https getting this issue?

4B. If you are running a cert, is it possible to remove and test https without it on your system?

Edited March 17, 2018 by cayars

[extensive 20]

Couple questions for you guys.

1. This only happens for https correct?

2. When you can't connect over https can you still access Emby over http?

3. Do any of you guys have IP6 bound?

4A. Is anyone NOT using a cert but just https getting this issue?

4B. If you are running a cert, is it possible to remove and test https without it on your system?

1 yes

2 yes

3 no

4b I would rather not but can later

[Luke 42077]

Well i really love emby so i will hold out for a resolution to this issue for now , i am in no mood to change what i have working right now. Perhaps M$ is responsible with some stupid update they force on you, win7 is what i use and it just did some updates on the same day. I have confidence the dev team will tell us something when they know something themselves.

 

hi @@socketman, please attach an emby server log from when this happened, thanks.

[Luke 42077]

Also @@Jdiesel there's a few 3.2.70.X betas still on github. Maybe you could step through a few of those to further isolate when it started? thanks.

[lorac 118]

Couple questions for you guys.

1. This only happens for https correct?

2. When you can't connect over https can you still access Emby over http?

3. Do any of you guys have IP6 bound?

4A. Is anyone NOT using a cert but just https getting this issue?

4B. If you are running a cert, is it possible to remove and test https without it on your system?

1. No

2. Not using https as it was too problematic

3. No

[Luke 42077]

1. No

2. Not using https as it was too problematic

3. No

 

I think your issue is isolated and unrelated to this topic, thanks.

[mbnwa 49]

I have still not been able to duplicate this issue, I have been trying to get it to break however had no luck.

 

I have enabled / disabled IPv6

I have enabled / disabled TLS/SSL with valid cert

 

Maybe it's plugin related or something external, firewall, etc - I have all firewall software disabled as I use PFSense for all my security needs - It would be interesting to see if everyone that has this issue has something in common (Plugin, Firewall software, Anti-Virus, etc) maybe the issue is not in Emby maybe the issue lies outside of Emby at the network stack level and it's interaction with 3rd party or OEM software.

 

One other thing is everyone that is having this issue all on Windows? I have seen Windows firewall do some stupid stuff in the past hence the reason why I fully disable it. (I have also seen bit defender and other external security software block legit traffic for example my neighbor was not able to use her printer due to the way Bit Defender setup it's rules, I would correct it for her and they would do an update and it would be broke again, that's just an example of something external causing issues.)

Edited March 18, 2018 by mbnwa

[Jdiesel 1431]

I am on Linux. IPv6 disabled. When it goes down I can not connect over https or http. No activity in log files as if the server has crashed but the process is still running. Need to restart the service to get everything back up.

[Carlo 4560]

I am on Linux. IPv6 disabled. When it goes down I can not connect over https or http. No activity in log files as if the server has crashed but the process is still running. Need to restart the service to get everything back up.

This seems to be different than others.  You seem to get locked out on both https and http while others are just getting hung up on https.

 

When this happens from the server machine can you get to the http or https ports?

[leekingsnatch 5]

For what it's worth, I'm having the exact same issues. Emby on Windows stops responding to external https requests even though http is still alive. Restarting Emby helps but sometimes it goes right back down after a few minutes. Sometimes it takes hours or sometimes days. There is no pattern as far as I can tell. I'm using a 3rd party cert. I'm on version 3.3.1.0.

 

So, I ended creating a Nginx reverse proxy to proxy https connections to the Emby http port in order to work around this issue. If anyone cares, here's my config:

 

The "set_real_ip_from 192.168.xxx.xxx" IP address is the IP of you nginx machine and the "proxy_pass http://192.xxx.xxx.xxx:8096"is the IP of your emby machine. Also ensure that you you uncheck " Require https for external connections" under "Expert --> Advanced" in Emby.

server {
        listen              443 ssl;
        server_name         emby.domain.tld;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
        keepalive_timeout   70;

        ssl_certificate     /etc/nginx/ssl/emby_cert.pem;
        ssl_certificate_key /etc/nginx/ssl/emby_key.key;
        ssl_protocols       TLSv1.2;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        set_real_ip_from 192.168.xxx.xxx;
        real_ip_header X-Real-IP;
        real_ip_recursive on;
location / {
          proxy_pass http://192.xxx.xxx.xxx:8096;
          proxy_redirect off;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

for those using pfsense, you can use the squid proxy package to accomplish the same thing.

Edited March 18, 2018 by leekingsnatch

[Jdiesel 1431]

This seems to be different than others. You seem to get locked out on both https and http while others are just getting hung up on https.

 

When this happens from the server machine can you get to the http or https ports?

Just realized that have "Require https for external connections" enabled which would explain why http doesn't work either. I've disabled it for the time being so I can test if http still works next time it goes down.

[Jdiesel 1431]

For what it's worth, I'm having the exact same issues. Emby on Windows stops responding to external https requests even though http is still alive. Restarting Emby helps but sometimes it goes right back down after a few minutes. Sometimes it takes hours or sometimes days. There is no pattern as far as I can tell. I'm using a 3rd party cert. I'm on version 3.3.1.0.

 

So, I ended creating a Nginx reverse proxy to proxy https connections to the Emby http port in order to work around this issue. If anyone cares, here's my config:

 

The "set_real_ip_from 192.168.xxx.xxx" IP address is the IP of you nginx machine and the "proxy_pass http://192.xxx.xxx.xxx:8096"is the IP of your emby machine. Also ensure that you you uncheck " Require https for external connections" under "Expert --> Advanced" in Emby.

server {
	    listen			  443 ssl;
	    server_name		 emby.domain.tld;
	    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
	    keepalive_timeout   70;

	    ssl_certificate	 /etc/nginx/ssl/emby_cert.pem;
	    ssl_certificate_key /etc/nginx/ssl/emby_key.key;
	    ssl_protocols	   TLSv1.2;
	    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
	    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
	    ssl_prefer_server_ciphers on;
	    ssl_session_cache shared:SSL:10m;
	    set_real_ip_from 192.168.xxx.xxx;
	    real_ip_header X-Real-IP;
	    real_ip_recursive on;
location / {
		  proxy_pass http://192.xxx.xxx.xxx:8096;
		  proxy_redirect off;
		  proxy_set_header Host $host;
		  proxy_set_header X-Real-IP $remote_addr;
		  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
} 

for those using pfsense, you can use the squid proxy package to accomplish the same thing.

I have decided to go back to using a nginx reverse proxy and bypass Emby's internal handling of https.

[zirus 0]

Hi,

 

I've also been experiencing this for about a month now, https  seems to fall over, but i'm still able to access it via http

 

I seem to be able to kill the https connections if i leave emby paused for a while.

 

What I have noticed is there seems to be a lot of ports that stuck in a state of "CLOSE_WAIT" eg 

 

There were about 3 pages that i saw before i restarted emby to get it working again.

 

Here is also my log

emby.txt

 

[Jdiesel 1431]

I wonder if it is related to these errors that I'm seeing in my log files

2018-03-09 16:13:17.366 Error HttpServer: Error in ProcessAccept
	*** Error Report ***
	Version: 3.3.1.3
	Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
	Operating system: Unix 4.4.0.112
	64-Bit OS: True
	64-Bit Process: True
	User Interactive: True
	Processor count: 8
	Program data path: /var/lib/emby
	Application directory: /opt/emby-server/system
	System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
	   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
	   at System.Net.Security.SslStream.AuthenticateAsServer(X509Certificate serverCertificate, Boolean clientCertificateRequired, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
	   at SocketHttpListener.Net.HttpConnection..ctor(ILogger logger, Socket socket, EndPointListener epl, Boolean secure, X509Certificate cert, ICryptoProvider cryptoProvider, IMemoryStreamFactory memoryStreamFactory, ITextEncoding textEncoding, IFileSystem fileSystem, IEnvironmentInfo environment)
	   at SocketHttpListener.Net.EndPointListener.ProcessAccept(Socket accepted)
	System.IO.IOException
	   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
	   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
	   at System.Net.Security.SslStream.AuthenticateAsServer(X509Certificate serverCertificate, Boolean clientCertificateRequired, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
	   at SocketHttpListener.Net.HttpConnection..ctor(ILogger logger, Socket socket, EndPointListener epl, Boolean secure, X509Certificate cert, ICryptoProvider cryptoProvider, IMemoryStreamFactory memoryStreamFactory, ITextEncoding textEncoding, IFileSystem fileSystem, IEnvironmentInfo environment)
	   at SocketHttpListener.Net.EndPointListener.ProcessAccept(Socket accepted)

[extensive 20]

happened yet again.  I have 0 confidence in my emby solution for my family. can we please get an update on this.

[Jdiesel 1431]

Not a solution to the root issue but I decided to try moving the handling of https to a reverse proxy. 24 hours in and no more issues. I'm not sure what the cause of the issue was but I was willing to try anything at this point.

[Luke 42077]

We are still looking into it. Best thing to do would be to hop on the beta server and see if anything changes. Thanks.

[mskenny 8]

I'm not sure if this is the same issue but I am having a similar problem.  It usually happens if I stop watching one channel and go back to the guide and try to watch another. Here are the recent logs.

 

Melissa

server-63657100800.txt

ffmpeg-transcode-18177545-7cda-4616-b6ae-c3dbf243d107.txt

ffmpeg-transcode-a6efce19-49e5-4f2b-b280-343bd9fdd320.txt

[extensive 20]

interesting information, not convinced it is fixed but wanted to pass it on.

 

i uninstalled playon, not the plugin, the actual app.  theory is the mobile site that it sets up on another port was doing something.

 

i moved my cert off of my pooled drivebender pool and onto my NVME boot drive.  not exactly sure how emby accesses the cert (if emby loads it in memory upon startup or actually interfaces with it directly each request)

theory is if it is actually accessing it directly then it would be much faster.

 

i changed the "External Domain" option in Emby dashboard under advanced from https://server.server.com to just server.server.com because that is what the instructions elude to

"If you have a dynamic DNS enter it here. Emby apps will use it when connecting remotely. This field is required when used with a custom ssl certificate. Example: mydomain.com."

 

anyways, it has been stable going on 4 days

Edited March 23, 2018 by extensive

[Luke 42077]

interesting information, not convinced it is fixed but wanted to pass it on.

 

i uninstalled playon

i moved my cert off of my pooled drivebender pool and onto my NVME boot drive

i changed the "External Domain" option in Emby dashboard under advanced from https://server.server.com to just server.server.com because that is what the instructions elude to

"If you have a dynamic DNS enter it here. Emby apps will use it when connecting remotely. This field is required when used with a custom ssl certificate. Example: mydomain.com."

 

anyways, it has been stable going on 4 days

 

Are you on the beta or stable server? Yes that field should not have the scheme included, but I think we are checking for that internally anyway. I will double check.

[extensive 20]

Are you on the beta or stable server? Yes that field should not have the scheme included, but I think we are checking for that internally anyway. I will double check.

sorry i meant to put this info in my post as well.

 

i am on Version 3.3.1.0

[Luke 42077]

Having the scheme https:// will not matter because we ignore it anyway. if any of you could try the latest beta server and see how that compares, that would be helpful. thanks.

[extensive 20]

Having the scheme https:// will not matter because we ignore it anyway. if any of you could try the latest beta server and see how that compares, that would be helpful. thanks.

you suggesting that none of my changes have affected the root issue and that it is just chance ive been stable for 4 days?  i figured as much   i will be honest, i haven't done much streaming from the browser in these 4 days.

[Luke 42077]

Well the server config change you made should not have any impact, no.

[Jdiesel 1431]

I switched back to using a pfx directly in Emby after having issues on with my nginx reverse proxy and Roku clients. Currently on server version 3.3.1.7. I will see if it still stops responding like it was before.

 

A bit of history of my testing/experiences with https over the last few months.

• Have been using a signed Comodo SSL certificate directly in Emby (.pfx) since August 2017. The certificate is valid until August 2020 and has a password. Worked great on all devices and never had any issues.
• Started running into issues where my server would become unresponsive over https and needed a restart somewhere between 3.2.7.6 and 3.2.7.16.
• Issue still existed as of 3.3.1.6
• Switched to a nginx reverse proxy with a letsencrypt certificate on server version 3.3.1.6. Server no longer became unresponsive over https however playback over https on the Roku clients does not work.
• Tried generating a letsencrypt pfx and using it directly in Emby however the Roku rejects the certificate completely, is good on a web browser and Android.
• Upgraded to 3.3.1.7 and installed the Comodo pfx in Emby. Playback works on all devices, will need to wait and see if server becomes unresponsive over https with time.

So I don't know if there is something going on with letsencrypt certs or if the Roku is just very picky about signed certs. I'd like to test the Comodo cert in a nginx reserve proxy but it is a real pain to generate a new one for my nginx config and haven't had the time.

Edited March 24, 2018 by Jdiesel