Emby 4.10.2.0 leaves orphaned Live TV stream after overlapping Samsung playback requests

[hiimcourty 4]

Emby Server 4.10.2.0 on Windows 11, Samsung Emby 2.3.6, M3U Live TV tuner with Rebel IPTV.

 

October 25, 2026 (Pacific): At ~6:43:28 AM overlapping Samsung TV playback-info requests for Food Network created TWO consumers of the same SharedHttpPipelineSource. Emby log reported consumer count 2. At 7:50:08 AM the tracked playback went idle, was stopped and removed; consumer count only fell to 1. The second consumer was not subsequently removed. Hours later Emby Sessions API showed zero NowPlaying sessions, but EmbyServer.exe still had its original established TCP connection to the M3U backend from 6:43 AM. Rebel showed Food Network active even as its total viewer metric fluctuated between 0 and 1. Stopping Food Network in Rebel did not permanently stop the stream. Restarting Emby at ~11:43 AM cleared the orphan, with Rebel showing 0 viewers and 0 feeds.

 

Expected: concurrent playback-info calls should not create a permanently untracked consumer; all upstream streams should close when their legitimate playback sessions end. Is this a known SharedHttpPipelineSource consumer-count bug? Is there a supported workaround without modifying Emby's build or disrupting current viewers?

 

Can supply anonymized logs privately upon request.

[Luke 43451]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[hiimcourty 4]

Thanks, Luke. I have the complete archived Emby Server log from October 25, 2026 (pre-restart), but it includes private hostnames, IP addresses, URL/query parameters, internal identifiers and local file paths. Rather than uploading that raw log publicly, here is a targeted, anonymized extraction of the exact playback/consumer lifecycle events. All timestamps are Pacific Daylight Time (UTC-7), October 25, 2026.

 

06:43:22.719 LiveTV: Streaming Channel [Food Network], with streamId: STREAM_1

06:43:28.792 SharedHttpPipelineSource: LiveStream consumerId added: CONSUMER_A

06:43:28.792 SharedHttpPipelineSource: Live stream STREAM_1 consumer count is now 1

06:43:28.792 SharedHttpPipelineSource: LiveStream consumerId added: CONSUMER_B

06:43:28.792 SharedHttpPipelineSource: Live stream STREAM_1 consumer count is now 2

06:43:28.792 SessionManager: Setting _lastPlaySessionId for session [REDACTED] to CONSUMER_A

06:43:28.793 SessionManager: Setting _lastPlaySessionId for that SAME session to CONSUMER_B

06:43:30.292 SessionManager: Playback start reported by app Emby for Samsung 2.3.6 on Samsung Smart TV playing Food Network. PlaySessionId: CONSUMER_B

07:50:08.333 SessionManager: PlaySession CONSUMER_B has gone idle while playing

07:50:08.333 SessionManager: Playback stopped reported by app Emby for Samsung 2.3.6 on Samsung Smart TV playing Food Network. PlaySessionId: CONSUMER_B

07:50:08.333 SharedHttpPipelineSource: LiveStream consumerId removed: CONSUMER_B

07:50:08.333 SharedHttpPipelineSource: Live stream STREAM_1 consumer count is now 1

11:42:47.917 MediaSourceManager: Closing live stream [REDACTED]_STREAM_1 (on Emby shutdown)

11:42:48.290 MediaSourceManager: Live stream [REDACTED]_STREAM_1 closed successfully

 

A search of the complete pre-restart server log finds CONSUMER_A being added and set as _lastPlaySessionId but no matching consumer removal before shutdown. Emby Sessions API reported zero NowPlaying users while EmbyServer.exe held its original HTTP connection to the IPTV backend, established at 06:43:22. The IPTV backend continued reporting Food Network active; manually stopping it there did not keep it stopped. Restarting Emby at ~11:43 AM released the source immediately; the backend then showed zero active feeds/viewers. No reproduction or configuration changes have been attempted since.

 

I also checked the available ffmpeg/transcode/remux/directstream log directory and found no new ffmpeg logs dated October 25 for this incident (the newest of those logs were from October 24).

 

What secure/private method would you prefer for providing the FULL complete server log, including only a dashboard-downloaded sanitized version if that is sufficient? I don't want to expose private URLs, hostnames, access parameters, household names, or local paths publicly. The original archived pre-restart log is retained.

[Luke 43451]

OK we are looking into it. Thanks.