Project

General

Profile

Bug #5985

When switching adaptar while live-streaming only first client stream continues

Added by r 2 6 months ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Category:
Streaming
Target version:
-
Start date:
2020-12-11
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1916~g1884300f0
Affected Versions:

Description

Hi... All
I'm testing the robustness of the streaming component over a set of failover scenearios. One of them is quite curious, having more than one adapter supporting the same services/muxes (SatIP receiver + DVBS Receiver (encrypted channel)) and 2 or more kodi clients seeing the same channel so using the same adapter at that time.
if I disable the adapter responsible of that stream, tvheadend automatically switch to a second adapter, but only the client who FIRST subscribed to that channel is able to automatically continue with the the stream (with the obvious short discontinuity errors). The other client/s always get a channel freeze, being needed to stop/start the channel again.
This happens indenpendently of the client architecture (Intel X86 VAAPI decoder, Raspberry MMAL, FireTv MediaCoder...), so seems to be related to server side issue.
Using HTSP or pass profile produces the same outcome.
Regards,

History

#1

Updated by r 2 6 months ago

r 2 wrote:

Hi... All
I'm testing the robustness of the streaming component over a set of failover scenearios. One of them is quite curious, having more than one adapter supporting the same services/muxes (SatIP receiver + DVBS Receiver (encrypted channel)) and 2 or more kodi clients seeing the same channel so using the same adapter at that time.
if I disable the adapter responsible of that stream, tvheadend automatically switch to a second adapter, but only the client who FIRST subscribed to that channel is able to automatically continue with the the stream (with the obvious short discontinuity errors). The other client/s always get a channel freeze, being needed to stop/start the channel again.
This happens indenpendently of the client architecture (Intel X86 VAAPI decoder, Raspberry MMAL, FireTv MediaCoder...), so seems to be related to server side issue.
Using HTSP or pass profile produces the same outcome.
Regards,

I forgot to mention, this also happens when there are some servere puntual continuity errors with a channel stream, but that scenario is harder to replicate it, meanwhile the issue described here it's a lot easier and happens always and seems to have the same root cause.

#2

Updated by r 2 6 months ago

I forgot to mention, this also happens when there are some servere punctual continuity errors with a channel stream, but that scenario is harder to replicate it, meanwhile the issue described here it's a lot easier, happens always and seems to have the same root cause.

Also available in: Atom PDF