Error after pause

[Bonfi 2]

I've been quite busy lately, so I didn't have the time to make more tests, but it still bothering me.

[Luke 37123]

I did some testing with different browsers. When you pause in Chrome, the server keeps trying to write to the network stream but Chrome has a nice way of stalling it, keeping the stream open but without any data moving. Firefox on the other hand doesn't do this and just allows emby server to keep writing the output to the network stream, which theoretically could eventually fill up the memory buffer or disk buffer on the client device.

 

I think what is happening is that the way Chrome stalls the network stream possibly causes the proxy to think it has disconnected altogether, which causes it to eventually terminate the connection. Either that or something the proxy does causes Chrome to think the server has closed the connection, so it then hangs up.

 

Does the proxy have any settings regarding closing connections or keeping them open?

[Bonfi 2]

I already tried to increase the keepalive_timeout option as well as the proxy_timeout and the proxy_connect_timeout with no effect.

But at this point I think a lower timeout should impact all the browsers, I am wrong?

[Luke 37123]

I'm not sure as it seems they handle pausing differenty

[Bonfi 2]

I'll try again with every possible timeout on the reverse proxy side.

[jpaytoncfd 5]

Anyone gotten any further on this issue? I am noticing the same thing. 

[meowers 0]

I've been using Emby for about 2 weeks now and I'm having the exact same issue. I'm using Nginx 1.4.6 as a proxy. I've noticed when I use chrome I get the playback error, but if i go directly to Emby using the IP and port, bypassing Nginx I don't have the issue anymore. I tested this in Chrome 50 and Canary. 

 

I did the same test with Firefox but I was unable to reproduce the error. 

[Luke 37123]

I've been using Emby for about 2 weeks now and I'm having the exact same issue. I'm using Nginx 1.4.6 as a proxy. I've noticed when I use chrome I get the playback error, but if i go directly to Emby using the IP and port, bypassing Nginx I don't have the issue anymore. I tested this in Chrome 50 and Canary. 

 

I did the same test with Firefox but I was unable to reproduce the error. 

 

The explanation of why it happens in Chrome is in post #27. I believe the proxy is closing the connection because it thinks the two sides have disconnected. After the error occurs, are you at least able to resume from the same spot?

[dcrdev 251]

I'm also experiencing this problem with an Apache reverse proxy - this definitely didn't use to happen so I'm wondering if something in Emby has changed. Anyway since the reverse proxy set up isn't an officially supported set up, I'll try and fix myself; off the bat I'm thinking that messing with Apaches KeepAlive directives should fix the problem. I'll post an update once I've tried it.

 

@@Luke in answer to your question, when playback fails it does not record the resume point which is potentially another issue. If you close the video instead of pausing it does record the resume point.

Edited May 16, 2016 by dcrdev

[quentinus95 0]

The issue is still here, using Nginx 1.9.

I wasn't having this issue using Plex in the past, by the way.

This issue is really annoying and I often switch to other streamng solutions when I know I will have to pause playback.

@@Luke, if you have any time, could you try to solve the issue ? I think it is more Emby-related than Nginix or Apache (I have tried a lot of different configurations, no solution so far).

Thanks a lot !

[frosteddark 1]

I've got the same issue and am willing to help troubleshoot.  I'm a highly technical enterprise sysadmin with full stack development experience in python & html (so I can be dangerous).  I just have no idea where to start inside Emby.
 
Like others, I have no issues when going direct to the Emby server.  However, when going through the proxy which is publicly accessible, I have the issue.  It's reproducible 95% of the time by playing a file, pausing for 60 seconds, un-pausing, and an error within 2 seconds.  The other 5% of the time, it works fine after resuming and will error out after the second pause (maybe I didn't wait long enough).
 
I've tried this from at least 4 locations, different ISPs, on different ends of the US (near and far from the Emby server), so I don't think its ISP related.
 
Emby: emby 3.0.5972.0 on Ubuntu 16.04
Proxy: nginx 1.10.0 on Ubuntu 16.04
 
One thing I did notice when digging into the proxy logs is that after about 60 seconds paused, there's a GET request to /emby/videos.. could that be destroying the paused session, causing the error?
 
Here's detailed logs from nginx if it helps..
 

# play
[16/Jun/2016:10:32:41 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 304 / upstream 304 GET /web/bower_components/emby-webcomponents/icons/nav.html HTTP/1.1 upstream_response_time 0.003 msec 1466098361.720 request_time 0.003 body: -
[16/Jun/2016:10:32:43 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 GET /emby/Users/ab66a4a8b672441b9a269639ee4684bb/Items/5409eb78a5750690541aa30a0b4b41b1 HTTP/1.1 upstream_response_time 0.126 msec 1466098363.195 request_time 0.126 body: -
[16/Jun/2016:10:32:43 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 GET /emby/Shows/2a0530902a2354b4bcb2952213bcd95b/Episodes?IsVirtualUnaired=false&IsMissing=false&UserId=ab66a4a8b672441b9a269639ee4684bb&Fields=MediaSources%2CChapters HTTP/1.1 upstream_response_time 0.606 msec 1466098363.983 request_time 0.766 body: -
[16/Jun/2016:10:32:44 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 GET /emby/Users/ab66a4a8b672441b9a269639ee4684bb/Items/5409eb78a5750690541aa30a0b4b41b1/Intros HTTP/1.1 upstream_response_time 0.004 msec 1466098364.114 request_time 0.004 body: -
[16/Jun/2016:10:32:45 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 POST /emby/Items/5409eb78a5750690541aa30a0b4b41b1/PlaybackInfo?UserId=ab66a4a8b672441b9a269639ee4684bb&StartTimeTicks=0 HTTP/1.1 upstream_response_time 0.006 msec 1466098365.811 request_time 0.007 
[16/Jun/2016:10:32:55 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing HTTP/1.1 upstream_response_time 0.021 msec 1466098375.881 request_time 0.021 
[16/Jun/2016:10:32:56 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.013 msec 1466098376.154 request_time 0.014 
[16/Jun/2016:10:33:01 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.005 msec 1466098381.618 request_time 0.006 
[16/Jun/2016:10:33:06 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.006 msec 1466098386.627 request_time 0.006 
[16/Jun/2016:10:33:12 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.007 msec 1466098392.619 request_time 0.007 


# while paused
[16/Jun/2016:10:34:01 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.006 msec 1466098441.613 request_time 0.006 
... (more progress entries)
[16/Jun/2016:10:35:08 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.005 msec 1466098508.007 request_time 0.005 
PROBLEM? --> [16/Jun/2016:10:35:09 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 GET /emby/videos/5409eb78a5750690541aa30a0b4b41b1/stream.mkv?DeviceId=<device-id-was-here>&MediaSourceId=5409eb78a5750690541aa30a0b4b41b1&VideoCodec=h264&AudioCodec=mp3&AudioStreamIndex=1&VideoBitrate=9680000&AudioBitrate=320000&MaxAudioChannels=6&Level=51&Profile=high&PlaySessionId=11a48d2fdc174dd5b6b6f34442ee0a19&api_key=<api-key-was-here>&CopyTimestamps=true&ForceLiveStream=false HTTP/1.1 upstream_response_time 57.345 msec 1466098509.245 request_time 134.842 body: -
[16/Jun/2016:10:35:13 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.005 msec 1466098513.922 request_time 0.006 
... (more progress entries)
[16/Jun/2016:10:35:24 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.005 msec 1466098524.921 request_time 0.005 


# resume
[16/Jun/2016:10:35:42 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.005 msec 1466098542.354 request_time 0.006 
[16/Jun/2016:10:35:49 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 GET /emby/videos/5409eb78a5750690541aa30a0b4b41b1/stream.mkv?DeviceId=<device-id-was-here>&MediaSourceId=5409eb78a5750690541aa30a0b4b41b1&VideoCodec=h264&AudioCodec=mp3&AudioStreamIndex=1&VideoBitrate=9680000&AudioBitrate=320000&MaxAudioChannels=6&Level=51&Profile=high&PlaySessionId=11a48d2fdc174dd5b6b6f34442ee0a19&api_key=<api-key-was-here>&CopyTimestamps=true&ForceLiveStream=false HTTP/1.1 upstream_response_time 2.358 msec 1466098549.390 request_time 2.358 body: -
[16/Jun/2016:10:35:49 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 DELETE /emby/Videos/ActiveEncodings?deviceId=<device-id-was-here> HTTP/1.1 upstream_response_time 0.085 msec 1466098549.475 request_time 0.085 body: -
[16/Jun/2016:10:35:49 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 200 / upstream 200 POST /emby/Items/0757d819025c27d223967234d6c3a980/PlaybackInfo?UserId=ab66a4a8b672441b9a269639ee4684bb&StartTimeTicks=0 HTTP/1.1 upstream_response_time 0.090 msec 1466098549.480 request_time 0.090 
[16/Jun/2016:10:35:49 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Stopped HTTP/1.1 upstream_response_time 0.110 msec 1466098549.500 request_time 0.110 
[16/Jun/2016:10:35:51 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing HTTP/1.1 upstream_response_time 0.009 msec 1466098551.209 request_time 0.010 
[16/Jun/2016:10:35:51 -0700] 1.2.3.4 - - - media.domain.com to: 192.168.1.20:8096: 204 / upstream 204 POST /emby/Sessions/Playing/Progress HTTP/1.1 upstream_response_time 0.006 msec 1466098551.622 request_time 0.006 

Logs with the POST body are here: https://dpaste.de/GG4s/raw (expires 2016-07-15)

[outlawman 4]

I have the same issue...using Windows Server R2 2012, and Windows 8.1 machines, all with this issue, using the web app, please help

Edited June 21, 2016 by outlawman

[Stephen2 0]

I notice a lot of this thread is pointing at nginx.  My situation is slightly different... It's when connected via OpenVPN to the network.  Not sure if this affects anything, but there is no nginx proxying involved.

 

I'm also using Chrome latest (51 at time of writing), and Emby is hosted on Archlinux.

 

Logs show the same error mentioned elsewhere (Write Failure at NetworkStream.Write)

 

Let me know if you'd like me to post logs or anything...

Edited June 22, 2016 by Stephen2

[Stephen2 0]

Oh yeah, my workaround is - instead of unpausing, I'll move the slider back by a few seconds or whatever, which makes this error not occur.

[frosteddark 1]

For me, I just X out of the video while it's playing (in Emby.. not the browser).  Since Emby reports your playback position every few seconds, when you refresh the page it shows the updated playback progress.  You can then resume like normal.  

[frosteddark 1]

I just upgraded to beta 3.1.70 and this appears to be resolved now.

 

I found "Improve error handling when transcode fails to start" in the release notes for release 3.0.5986 so that could be it.

[Luke 37123]

I'm glad to hear this but surprised to be honest.

[Smatthew 0]

i've been having this same problem, even posted a thread

 

http://emby.media/community/index.php?/topic/35722-video-error-after-resuming-video/?p=342850

 

 

I am, however, not using any proxy.  I am on Win10

 

i only found this post by searching for "The client has most likely disconnected or transcoding has failed." which i saw in the log.

 

 

log.txt

Edited July 21, 2016 by Smatthew