m3u stays connected after ungraceful client exit

[danlo315 6]

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?

[Luke 37057]

Hi, in most cases it should disconnect within several minutes. It's still an area we can improve on in the future. Thanks.

[danlo315 6]

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.

[speechles 1917]

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.

[Q-Droid 641]

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.

[danlo315 6]

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.

[Soggybottoms 3]

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

[danlo315 6]

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.

[Luke 37057]

We'll look at improving this, thanks guys.

[danlo315 6]

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.

[Luke 37057]

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?

[danlo315 6]

What exactly did you do?

I wish I knew, since it was my girlfriend switching between channels.

[Luke 37057]

If you can reproduce it then let's look at it in detail with the latest version. Thanks.

[danlo315 6]

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.

[Luke 37057]

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.

[danlo315 6]

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?

[Luke 37057]

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!

 

[danlo315 6]

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

[Luke 37057]

This was playing on android tv? How does playing in the web app compare?

[danlo315 6]

This was playing on Android TV but I've seen the same behavior on all different clients (web, Apple TV). 

[Luke 37057]

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.

[danlo315 6]

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?

[Luke 37057]

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.

[danlo315 6]

I can give you the web server log that does *not* give me this problem. Does that help?

[Luke 37057]

No, so you're saying you can't get this to happen at all in the web app?