Live TV Stream just randomly disconnects

[roberto188 33]

A user of mine, outside of my local network, streams TV from my Emby server. Randomly he gets disconnected and the log shows the following:

 

Any idea what is causing this?
 

Error HttpServer: Error in HttpListenerResponseWrapper: An existing connection was forcibly closed by the remote host

*** Error Report ***

Version: 3.3.1.11

Command line: C:\Users\Media Center\AppData\Roaming\Emby-Server\system\EmbyServer.dll

Operating system: Microsoft Windows NT 6.1.7601 Service Pack 1

64-Bit OS: True

64-Bit Process: True

User Interactive: True

Processor count: 4

Program data path: C:\Users\Media Center\AppData\Roaming\Emby-Server\programdata

Application directory: C:\Users\Media Center\AppData\Roaming\Emby-Server\system

System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)

   at SocketHttpListener.SocketStream.Write(Byte[] buffer, Int32 offset, Int32 count)

   at SocketHttpListener.Net.HttpResponseStream.InternalWrite(Byte[] buffer, Int32 offset, Int32 count)

   at SocketHttpListener.Net.HttpResponseStream.DisposeCore()

   at SocketHttpListener.Net.HttpResponseStream.Dispose(Boolean disposing)

   at System.IO.Stream.Close()

   at Emby.Server.Implementations.HttpServer.SocketSharp.WebSocketSharpResponse.CloseOutputStream(HttpListenerResponse response)

System.Net.Sockets.SocketException

   at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)

   at SocketHttpListener.SocketStream.Write(Byte[] buffer, Int32 offset, Int32 count)

   at SocketHttpListener.Net.HttpResponseStream.InternalWrite(Byte[] buffer, Int32 offset, Int32 count)

   at SocketHttpListener.Net.HttpResponseStream.DisposeCore()

   at SocketHttpListener.Net.HttpResponseStream.Dispose(Boolean disposing)

   at System.IO.Stream.Close()

   at Emby.Server.Implementations.HttpServer.SocketSharp.WebSocketSharpResponse.CloseOutputStream(HttpListenerResponse response)

 

2018-04-01 00:54:36.653 Info HttpServer: HTTP Response 500 to 127.0.0.1. Time: 264124ms. http://127.0.0.1:8096/LiveTv/LiveStreamFiles/a07713c793474a5e95c0d96b4622b45e/stream.ts 

2018-04-01 00:54:36.700 Debug App: Disposing stream resources

2018-04-01 00:54:36.700 Info App: Deleting partial stream file(s) D:\transcoding-temp\a50e36b306d531cea4b98957e1b81961.m3u8

2018-04-01 00:54:36.700 Info MediaSourceManager: Closing live stream 09efa0d56b934a82adec00a87b837fb0_5cd72f479395456da73032eca776fce3_native_0aab380020f970120dfd8999f8c52e64_ed86d5320b4ad6b9e828cc1c146a5d2b with provider LiveTvMediaSourceProvider

2018-04-01 00:54:36.700 Info App: Closing live stream from Emby, stream Id: 5cd72f479395456da73032eca776fce3_native_0aab380020f970120dfd8999f8c52e64_ed86d5320b4ad6b9e828cc1c146a5d2b

2018-04-01 00:54:36.700 Info App: Live stream 5cd72f479395456da73032eca776fce3_native_0aab380020f970120dfd8999f8c52e64_ed86d5320b4ad6b9e828cc1c146a5d2b consumer count is now 0

2018-04-01 00:54:36.700 Info App: Closing live stream 5cd72f479395456da73032eca776fce3_native_0aab380020f970120dfd8999f8c52e64_ed86d5320b4ad6b9e828cc1c146a5d2b

2018-04-01 00:54:36.700 Info App: Closing SharedHttpStream

2018-04-01 00:54:36.700 Info App: Live stream 5cd72f479395456da73032eca776fce3_native_0aab380020f970120dfd8999f8c52e64_ed86d5320b4ad6b9e828cc1c146a5d2b closed successfully

2018-04-01 00:54:36.700 Info App: FFMpeg exited with code 0

2018-04-01 00:54:36.700 Info App: Deleting temp files D:\transcoding-temp\a07713c793474a5e95c0d96b4622b45e.ts

 

[Luke 42078]

Please attach the complete emby server and ffmpeg log, thanks.

[roberto188 33]

The entire log file is 115 MB. Do you really want that? Maybe there is a point I can trunctate it for you? I can send you the point where the request for the stream is shown and where it terminates along with the FFMPEG log. Will that be sufficient or do you want me to send a Server log that spans 8 hours?

[Luke 42078]

The whole thing is fine.

[roberto188 33]

Logs attached. Had to zip them because of the 90MB limit.

Logs.zip

[Luke 42078]

Based on this transcode log it looks like it would have only played for a few seconds, is that correct? There are lots of things you can try here to try and narrow down the issue:

• lower the in-app bitrate setting
• reset the hidden yadif config switch to default
• reset other server transcoding settings to default
• disable nvenc, either on the decoding side, encoding side, or both

[roberto188 33]

Thanks. But this same user will be able to stream for 2 hours another time and then it will diaconnect just like this one did. It seems to be somewhat random . In this case it was only after a minute other cases will be 30 minutes others will be 2 hours. I don't think that would be indicative of transcoding settings. 

[roberto188 33]

This user also had these issues before the yadif option and before I enabled hardware transcoding. Typically when I stream within my network I can for hours with no issues . It seems like outside my local network the disconnects occur. 

[Luke 42078]

The bitrate being requested might be a little aggressive.

[roberto188 33]

8 megabits??? We both have gigabit internet .

[ebr 16176]

What version of the app? Do these "random" disconnects always happen right after a program change on the channel?

[Luke 42078]

You have a lot of customizations here that I mentioned above. This creates a lot of variables for us to test. I would suggest setting those things back to default and then work your way up from there.

[roberto188 33]

This are on the latest Beta version. I will look into the timing. Perhaps when a program is scheduled to end it disconnects? I want to say no because this instance was at X:17. I can't imagine a program ending at that time, but I'll see if when it happens again their is any correlation to the guide info of when the program is scheduled to end. 

[ebr 16176]

If you are on the beta, then it probably is not related to the program ending. I would do as Luke suggested and start with default settings to see if it is still a problem.

[roberto188 33]

Lowering the bitrate seems to help. Problem is 4mbit looks terrible.

[Luke 42078]

Thanks for the feedback.

[roberto188 33]

Still got the disconnect just a bit less frequent than with higher bitrate.

[roberto188 33]

Just One FYI. My user who was having disconnect issues has reported that with the Blue Neon app he hasn't had any disconnects. Not sure what the difference is but it works.

 

Also was able to bump bitrate back up to 8mbits without issue.

Edited April 16, 2018 by roberto188

[Luke 42078]

If you provide the ffmpeg log for both scenarios we can compare. Chances are it will be just be a coincidence, in all likelihood. Thanks.