danlo315 6 Posted May 8, 2019 Share Posted May 8, 2019 This is a follow-up to a previous post I had. For reference, I'm using TVHeadend 4.3 integrated with Emby via m3u and no user login via IP whitelisting. Both TVH and Emby running on Docker container. I continue to see connections staying open when a client didn't exit gracefully (i.e. Roku client exit to home without hitting back first, force closing an Android app). It doesn't happen all the time but it is frequent enough where I see open subscriptions in TVH when there are no active clients. Restarting the Emby server has always reset the connections for me so I can only assume that Emby does know these connections still exist, and it's not a TVH problem. Am I the only one seeing this issue? Link to comment Share on other sites More sharing options...
Luke 37113 Posted May 8, 2019 Share Posted May 8, 2019 Hi, in most cases it should disconnect within several minutes. It's still an area we can improve on in the future. Thanks. Link to comment Share on other sites More sharing options...
danlo315 6 Posted May 8, 2019 Author Share Posted May 8, 2019 Hi @@Luke, thanks for the response. I am seeing that only in some cases. There are times when the connection stays on for hours where I had to recycle the server for the connection to drop. I don't know if the streams were transcoding at the time but that could be part of it. Link to comment Share on other sites More sharing options...
speechles 1920 Posted May 9, 2019 Share Posted May 9, 2019 The apps send "heart beats" to the server. In the form of progress reports. When the server doesn't get these for awhile it decides when the app has left the building. Then ffmpeg should be terminated. It should also clear the active encodings for that transcoding session. Link to comment Share on other sites More sharing options...
Q-Droid 654 Posted May 9, 2019 Share Posted May 9, 2019 I've had the same issue where occasionally Emby holds on to the TVH stream after the client exits. It isn't always after a crash or ungraceful exit. Often there may be an issue during playback and I stop or change channel. Emby doesn't release the subscription though I can close the sub in the TVH admin without having to restart. Link to comment Share on other sites More sharing options...
danlo315 6 Posted May 9, 2019 Author Share Posted May 9, 2019 I've had the same issue where occasionally Emby holds on to the TVH stream after the client exits. It isn't always after a crash or ungraceful exit. Often there may be an issue during playback and I stop or change channel. Emby doesn't release the subscription though I can close the sub in the TVH admin without having to restart. I should clarify that the "ungraceful exit" isn't necessarily exiting a client, but exiting a stream, so I am seeing the same thing as you @@Q-Droid I have tried the closing subs in TVH but the connections seem to come back. The surefire way for me is to recycle the Emby server. Link to comment Share on other sites More sharing options...
Soggybottoms 3 Posted May 10, 2019 Share Posted May 10, 2019 (edited) I have this problem also from time to time.. My one big pet peeve with Emby is once you have a zombie session the only way I've been able to kill it is to restart the Emby service. I can see the zombie session(s) when running lsof and they all share the same PID, so unless there is a way to kill the thread it spawned running under the PID I'm not sure how to kill the session without having to restart the service. I just wish we had more granular control of the connections to/from the Emby server in addition to the dashboard showing us 'active' connections. Perhaps something like showing us the last 'x' connections made to/from the Emby server and allowing us to recycle (kill/pause/restart) zombie sessions.. Edited May 10, 2019 by Soggybottoms Link to comment Share on other sites More sharing options...
danlo315 6 Posted May 10, 2019 Author Share Posted May 10, 2019 I have this problem also from time to time.. My one big pet peeve with Emby is once you have a zombie session the only way I've been able to kill it is to restart the Emby service. I can see the zombie session(s) when running lsof and they all share the same PID, so unless there is a way to kill the thread it spawned running under the PID I'm not sure how to kill the session without having to restart the service. I just wish we had more granular control of the connections to/from the Emby server in addition to the dashboard showing us 'active' connections. Perhaps something like showing us the last 'x' connections made to/from the Emby server and allowing us to recycle (kill/pause/restart) zombie sessions.. My current resort is to have a crontab entry to restart the Emby Docker container every day. I am trying to make this as automated as possible. Link to comment Share on other sites More sharing options...
Luke 37113 Posted May 10, 2019 Share Posted May 10, 2019 We'll look at improving this, thanks guys. Link to comment Share on other sites More sharing options...
danlo315 6 Posted July 28, 2019 Author Share Posted July 28, 2019 Hey all, picking this back up. I am now on Beta 4.2.0.36 and I continue to see this issue. For those on TVH are you seeing the connections continue to persist? I have been pouring over the logs and something stood out. This is the initiation of the stream: 2019-07-28 10:10:02.327 Info HttpClient: Http response 200 from http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass after 2362ms. HeadersServer=HTS/tvheadend, Cache-Control=no-cache, Connection=close 2019-07-28 10:10:02.327 Info SharedHttpPipelineSource: Beginning SharedHttpPipelineSource stream to /config/transcoding-temp/fd7da00d7387454ba13b4b51de0ba2aa.ts2019-07-28 10:10:02.327 Info M3UTunerHost: Live stream opened after 2363.1925ms2019-07-28 10:10:02.327 Info LiveTV: Returning mediasource streamId c0ccebbd9173db09b1d35efc6affab40, mediaSource.Id c0ccebbd9173db09b1d35efc6affab40, mediaSource.LiveStreamId null2019-07-28 10:10:02.332 Info MediaSourceManager: Waiting 3000ms before probing the live stream2019-07-28 10:10:05.335 Info MediaEncoder: ProcessRun 'ffprobe' Execute: /bin/ffprobe -analyzeduration 3000000 -i "http://127.0.0.1:8096/LiveTv/LiveStreamFiles/fd7da00d7387454ba13b4b51de0ba2aa/stream.ts"-threads 0 -v info -print_format json -show_streams -show_format -show_data 2019-07-28 10:10:05.359 Info MediaEncoder: ProcessRun 'ffprobe' Started.2019-07-28 10:10:05.411 Info HttpServer: HTTP GET http://127.0.0.1:8096/LiveTv/LiveStreamFiles/fd7da00d7387454ba13b4b51de0ba2aa/stream.ts. UserAgent: Lavf/58.12.100 2019-07-28 10:10:10.657 Info HttpServer: HTTP POST https://vps2.danlo.org:8920/emby/Sessions/Playing/Progress. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.0.0; SHIELD Android TV Build/OPR6.170623.010) 2019-07-28 10:10:10.663 Info HttpServer: HTTP Response 204 to 74.64.182.116. Time: 6ms. https://vps2.danlo.org:8920/emby/Sessions/Playing/Progress2019-07-28 10:10:13.083 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/519944?format=json. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:13.096 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 13ms. https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/519944?format=json2019-07-28 10:10:13.786 Info SharedHttpPipelineSource: Opening SharedHttpPipelineSource Live stream from http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass2019-07-28 10:10:13.786 Info HttpClient: GET http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass2019-07-28 10:10:14.359 Info HttpClient: Http response 200 from http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass after 572ms. HeadersServer=HTS/tvheadend, Cache-Control=no-cache, Connection=close 2019-07-28 10:10:14.575 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Items/519948/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=de9b20ff08bb6b4194c1ab29d036a36c. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:14.580 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 5ms. https://vps2.danlo.org:8920/emby/Items/519948/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=de9b20ff08bb6b4194c1ab29d036a36c2019-07-28 10:10:15.092 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/525673?format=json. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:15.139 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 46ms. https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/525673?format=json2019-07-28 10:10:15.204 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Items/519949/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=2de0c92dd1ce4259e6dbe9521b342252. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:15.209 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 5ms. https://vps2.danlo.org:8920/emby/Items/519949/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=2de0c92dd1ce4259e6dbe9521b3422522019-07-28 10:10:15.337 Info MediaEncoder: ProcessRun 'ffprobe' Process exited with code 02019-07-28 10:10:15.338 Info MediaSourceManager: Live tv media info probe took 13.0103986 seconds2019-07-28 10:10:15.338 Info MediaSourceManager: Live stream opened: {"Protocol":"Http","Id":"c0ccebbd9173db09b1d35efc6affab40","Path":"http://127.0.0.1:8096/LiveTv/LiveStreamFiles/fd7da00d7387454ba13b4b51de0ba2aa/stream.ts","Type":"Default","Container":"mpegts","IsRemote":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":false,"IsInfiniteStream":true,"RequiresOpening":true,"RequiresClosing":true,"LiveStreamId":"06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c0ccebbd9173db09b1d35efc6affab40","RequiresLooping":false,"SupportsProbing":false,"MediaStreams":[{"Codec":"h264","TimeBase":"1/90000","CodecTimeBase":"1001/120000","VideoRange":"SDR","DisplayTitle":"720pH264","NalLengthSize":"0","IsInterlaced":false,"BitRate":8000000,"BitDepth":8,"RefFrames":1,"IsDefault":false,"IsForced":false,"Height":720,"Width":1280,"AverageFrameRate":59.94006,"RealFrameRate":59.94006,"Profile":"High","Type":"Video","AspectRatio":"16:9","Index":-1,"IsExternal":false,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Protocol":"File","PixelFormat":"yuv420p","Level":41,"IsAnamorphic":false},{"Codec":"aac","TimeBase":"1/90000","CodecTimeBase":"1/48000","DisplayTitle":"AAC stereo","IsInterlaced":false,"ChannelLayout":"stereo","BitRate":117750,"Channels":2,"SampleRate":48000,"IsDefault":false,"IsForced":false,"Profile":"LC","Type":"Audio","Index":-1,"IsExternal":false,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Protocol":"File","Level":0}],"Formats":[],"Bitrate":8117750,"RequiredHttpHeaders":{"User-Agent":"VLC/3.0.1"},"ReadAtNativeFramerate":false} There was an error: 2019-07-28 10:15:09.066 Info HttpServer: SocketException: https://vps2.danlo.org:8920/emby/Videos/519944/stream.mpegts?api_key=5fc765a251694e27ad9194b2b63ff909&DeviceId=54606f9213b147a1&MediaSourceId=c0ccebbd9173db09b1d35efc6affab40&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c0ccebbd9173db09b1d35efc6affab40&Static=true2019-07-28 10:15:09.068 Error HttpServer: Error in HttpListenerResponseWrapper: The WriteAsync method cannot be called when another write operation is pending. *** Error Report *** Version: 4.2.0.36 Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3 Operating system: Unix 4.4.0.141 64-Bit OS: True 64-Bit Process: True User Interactive: True Runtime: file:///system/System.Private.CoreLib.dll Processor count: 2 Program data path: /config Application directory: /system System.NotSupportedException: System.NotSupportedException: The WriteAsync method cannot be called when another write operation is pending. at System.Net.Security.SslStreamInternal.WriteAsyncInternal[TWriteAdapter](TWriteAdapter writeAdapter, ReadOnlyMemory`1 buffer) at System.Net.Security.SslStreamInternal.Write(Byte[] buffer, Int32 offset, Int32 count) at System.Net.Security.SslStream.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 EmbyServer.SocketSharp.WebSocketSharpResponse.Close() Source: System.Net.Security TargetSite: System.Threading.Tasks.ValueTask WriteAsyncInternal[TWriteAdapter](TWriteAdapter, System.ReadOnlyMemory`1[system.Byte]) 2019-07-28 10:15:09.068 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 293240ms. https://vps2.danlo.org:8920/emby/Videos/519944/stream.mpegts?DeviceId=54606f9213b147a1&MediaSourceId=c0ccebbd9173db09b1d35efc6affab40&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c0ccebbd9173db09b1d35efc6affab40&Static=true And the stream ID never showed up in the log again. This stream then is "stuck" as open with my TVH even though the device it's playing on switched to another channel. Link to comment Share on other sites More sharing options...
Luke 37113 Posted July 29, 2019 Share Posted July 29, 2019 Hey all, picking this back up. I am now on Beta 4.2.0.36 and I continue to see this issue. For those on TVH are you seeing the connections continue to persist? I have been pouring over the logs and something stood out. This is the initiation of the stream: 2019-07-28 10:10:02.327 Info HttpClient: Http response 200 from http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass after 2362ms. HeadersServer=HTS/tvheadend, Cache-Control=no-cache, Connection=close 2019-07-28 10:10:02.327 Info SharedHttpPipelineSource: Beginning SharedHttpPipelineSource stream to /config/transcoding-temp/fd7da00d7387454ba13b4b51de0ba2aa.ts 2019-07-28 10:10:02.327 Info M3UTunerHost: Live stream opened after 2363.1925ms 2019-07-28 10:10:02.327 Info LiveTV: Returning mediasource streamId c0ccebbd9173db09b1d35efc6affab40, mediaSource.Id c0ccebbd9173db09b1d35efc6affab40, mediaSource.LiveStreamId null 2019-07-28 10:10:02.332 Info MediaSourceManager: Waiting 3000ms before probing the live stream 2019-07-28 10:10:05.335 Info MediaEncoder: ProcessRun 'ffprobe' Execute: /bin/ffprobe -analyzeduration 3000000 -i "http://127.0.0.1:8096/LiveTv/LiveStreamFiles/fd7da00d7387454ba13b4b51de0ba2aa/stream.ts"-threads 0 -v info -print_format json -show_streams -show_format -show_data 2019-07-28 10:10:05.359 Info MediaEncoder: ProcessRun 'ffprobe' Started. 2019-07-28 10:10:05.411 Info HttpServer: HTTP GET http://127.0.0.1:8096/LiveTv/LiveStreamFiles/fd7da00d7387454ba13b4b51de0ba2aa/stream.ts. UserAgent: Lavf/58.12.100 2019-07-28 10:10:10.657 Info HttpServer: HTTP POST https://vps2.danlo.org:8920/emby/Sessions/Playing/Progress. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.0.0; SHIELD Android TV Build/OPR6.170623.010) 2019-07-28 10:10:10.663 Info HttpServer: HTTP Response 204 to 74.64.182.116. Time: 6ms. https://vps2.danlo.org:8920/emby/Sessions/Playing/Progress 2019-07-28 10:10:13.083 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/519944?format=json. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:13.096 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 13ms. https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/519944?format=json 2019-07-28 10:10:13.786 Info SharedHttpPipelineSource: Opening SharedHttpPipelineSource Live stream from http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass 2019-07-28 10:10:13.786 Info HttpClient: GET http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass 2019-07-28 10:10:14.359 Info HttpClient: Http response 200 from http://172.20.0.101:9981/tvh/stream/channelid/1803744080?profile=pass after 572ms. HeadersServer=HTS/tvheadend, Cache-Control=no-cache, Connection=close 2019-07-28 10:10:14.575 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Items/519948/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=de9b20ff08bb6b4194c1ab29d036a36c. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:14.580 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 5ms. https://vps2.danlo.org:8920/emby/Items/519948/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=de9b20ff08bb6b4194c1ab29d036a36c 2019-07-28 10:10:15.092 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/525673?format=json. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:15.139 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 46ms. https://vps2.danlo.org:8920/emby/Users/901b1a15ec874ec393f30f2da782dfb3/Items/525673?format=json 2019-07-28 10:10:15.204 Info HttpServer: HTTP GET https://vps2.danlo.org:8920/emby/Items/519949/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=2de0c92dd1ce4259e6dbe9521b342252. UserAgent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Jetstream AGT418 Build/NHG47L) 2019-07-28 10:10:15.209 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 5ms. https://vps2.danlo.org:8920/emby/Items/519949/Images/Primary?Accept=webp&EnableImageEnhancers=true&MaxHeight=370&Tag=2de0c92dd1ce4259e6dbe9521b342252 2019-07-28 10:10:15.337 Info MediaEncoder: ProcessRun 'ffprobe' Process exited with code 0 2019-07-28 10:10:15.338 Info MediaSourceManager: Live tv media info probe took 13.0103986 seconds 2019-07-28 10:10:15.338 Info MediaSourceManager: Live stream opened: {"Protocol":"Http","Id":"c0ccebbd9173db09b1d35efc6affab40","Path":"http://127.0.0.1:8096/LiveTv/LiveStreamFiles/fd7da00d7387454ba13b4b51de0ba2aa/stream.ts","Type":"Default","Container":"mpegts","IsRemote":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":false,"IsInfiniteStream":true,"RequiresOpening":true,"RequiresClosing":true,"LiveStreamId":"06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c0ccebbd9173db09b1d35efc6affab40","RequiresLooping":false,"SupportsProbing":false,"MediaStreams":[{"Codec":"h264","TimeBase":"1/90000","CodecTimeBase":"1001/120000","VideoRange":"SDR","DisplayTitle":"720pH264","NalLengthSize":"0","IsInterlaced":false,"BitRate":8000000,"BitDepth":8,"RefFrames":1,"IsDefault":false,"IsForced":false,"Height":720,"Width":1280,"AverageFrameRate":59.94006,"RealFrameRate":59.94006,"Profile":"High","Type":"Video","AspectRatio":"16:9","Index":-1,"IsExternal":false,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Protocol":"File","PixelFormat":"yuv420p","Level":41,"IsAnamorphic":false},{"Codec":"aac","TimeBase":"1/90000","CodecTimeBase":"1/48000","DisplayTitle":"AAC stereo","IsInterlaced":false,"ChannelLayout":"stereo","BitRate":117750,"Channels":2,"SampleRate":48000,"IsDefault":false,"IsForced":false,"Profile":"LC","Type":"Audio","Index":-1,"IsExternal":false,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Protocol":"File","Level":0}],"Formats":[],"Bitrate":8117750,"RequiredHttpHeaders":{"User-Agent":"VLC/3.0.1"},"ReadAtNativeFramerate":false} There was an error: 2019-07-28 10:15:09.066 Info HttpServer: SocketException: https://vps2.danlo.org:8920/emby/Videos/519944/stream.mpegts?api_key=5fc765a251694e27ad9194b2b63ff909&DeviceId=54606f9213b147a1&MediaSourceId=c0ccebbd9173db09b1d35efc6affab40&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c0ccebbd9173db09b1d35efc6affab40&Static=true 2019-07-28 10:15:09.068 Error HttpServer: Error in HttpListenerResponseWrapper: The WriteAsync method cannot be called when another write operation is pending. *** Error Report *** Version: 4.2.0.36 Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3 Operating system: Unix 4.4.0.141 64-Bit OS: True 64-Bit Process: True User Interactive: True Runtime: file:///system/System.Private.CoreLib.dll Processor count: 2 Program data path: /config Application directory: /system System.NotSupportedException: System.NotSupportedException: The WriteAsync method cannot be called when another write operation is pending. at System.Net.Security.SslStreamInternal.WriteAsyncInternal[TWriteAdapter](TWriteAdapter writeAdapter, ReadOnlyMemory`1 buffer) at System.Net.Security.SslStreamInternal.Write(Byte[] buffer, Int32 offset, Int32 count) at System.Net.Security.SslStream.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 EmbyServer.SocketSharp.WebSocketSharpResponse.Close() Source: System.Net.Security TargetSite: System.Threading.Tasks.ValueTask WriteAsyncInternal[TWriteAdapter](TWriteAdapter, System.ReadOnlyMemory`1[system.Byte]) 2019-07-28 10:15:09.068 Info HttpServer: HTTP Response 200 to 74.64.182.116. Time: 293240ms. https://vps2.danlo.org:8920/emby/Videos/519944/stream.mpegts?DeviceId=54606f9213b147a1&MediaSourceId=c0ccebbd9173db09b1d35efc6affab40&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c0ccebbd9173db09b1d35efc6affab40&Static=true And the stream ID never showed up in the log again. This stream then is "stuck" as open with my TVH even though the device it's playing on switched to another channel. What exactly did you do? Link to comment Share on other sites More sharing options...
danlo315 6 Posted July 30, 2019 Author Share Posted July 30, 2019 What exactly did you do? I wish I knew, since it was my girlfriend switching between channels. Link to comment Share on other sites More sharing options...
Luke 37113 Posted July 31, 2019 Share Posted July 31, 2019 If you can reproduce it then let's look at it in detail with the latest version. Thanks. Link to comment Share on other sites More sharing options...
danlo315 6 Posted August 12, 2019 Author Share Posted August 12, 2019 I was able to just reproduce the problem. I use TVHeadend as my backend. If the channel times out in Emby (due to the iptv channel not being tuned on fast enough), TVHeadend continues to connect. This will cause TVHeadend to continue to "stream" but leaves the connection open from Emby server. Link to comment Share on other sites More sharing options...
Luke 37113 Posted August 12, 2019 Share Posted August 12, 2019 I was able to just reproduce the problem. I use TVHeadend as my backend. If the channel times out in Emby (due to the iptv channel not being tuned on fast enough), TVHeadend continues to connect. This will cause TVHeadend to continue to "stream" but leaves the connection open from Emby server. Please attach the emby server log. thanks. Link to comment Share on other sites More sharing options...
danlo315 6 Posted October 26, 2022 Author Share Posted October 26, 2022 Resurrecting this legacy topic, as I have seen this happen more frequently in 4.7.8.0 vs 4.7.5.0 (did not go to .6 or .7). I am still on TVHeadend as backend and I have tried using direct m3u as well as the TVHeadend plugin (both essentially does the same thing with the plugin using ticket and m3u using token and/or username/password authentication). It's pretty intermittent and it always seem to be when users are impatient when the channels are loading and back out before it's loaded, but it's not easy to reproduce. How can I go about helping to provide a log for this? Link to comment Share on other sites More sharing options...
Luke 37113 Posted October 26, 2022 Share Posted October 26, 2022 1 hour ago, danlo315 said: Resurrecting this legacy topic, as I have seen this happen more frequently in 4.7.8.0 vs 4.7.5.0 (did not go to .6 or .7). I am still on TVHeadend as backend and I have tried using direct m3u as well as the TVHeadend plugin (both essentially does the same thing with the plugin using ticket and m3u using token and/or username/password authentication). It's pretty intermittent and it always seem to be when users are impatient when the channels are loading and back out before it's loaded, but it's not easy to reproduce. How can I go about helping to provide a log for this? @danlo315 Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks! Link to comment Share on other sites More sharing options...
danlo315 6 Posted October 27, 2022 Author Share Posted October 27, 2022 The log files are pretty huge as I couldn't parse this out. However I was able to pinpoint a particular instance. Here are the timestamps: 20:44:58 - Playback initiated to NBA03 20:45:04 - Playback initiated to NBA04 This is backed up by the Activity in the Dashboard with a "playing" but no "finishing: NBA03 is stuck as playing in my tvheadend. embyserver.txt.gz Link to comment Share on other sites More sharing options...
Luke 37113 Posted October 27, 2022 Share Posted October 27, 2022 This was playing on android tv? How does playing in the web app compare? Link to comment Share on other sites More sharing options...
danlo315 6 Posted October 27, 2022 Author Share Posted October 27, 2022 This was playing on Android TV but I've seen the same behavior on all different clients (web, Apple TV). Link to comment Share on other sites More sharing options...
Luke 37113 Posted October 27, 2022 Share Posted October 27, 2022 4 minutes ago, danlo315 said: This was playing on Android TV but I've seen the same behavior on all different clients (web, Apple TV). Please attach a server log example from the web app. Thanks. Link to comment Share on other sites More sharing options...
danlo315 6 Posted October 27, 2022 Author Share Posted October 27, 2022 I am having trouble trying to replicate this in the web app. Going to continue to try and replicate it. In the mean time, does the Android TV log help? 1 Link to comment Share on other sites More sharing options...
Luke 37113 Posted October 27, 2022 Share Posted October 27, 2022 1 minute ago, danlo315 said: I am having trouble trying to replicate this in the web app. Going to continue to try and replicate it. In the mean time, does the Android TV log help? I need the web app comparison first in order to help narrow down whether it's a client or server problem. Link to comment Share on other sites More sharing options...
danlo315 6 Posted October 27, 2022 Author Share Posted October 27, 2022 I can give you the web server log that does *not* give me this problem. Does that help? Link to comment Share on other sites More sharing options...
Luke 37113 Posted October 27, 2022 Share Posted October 27, 2022 No, so you're saying you can't get this to happen at all in the web app? 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