Bug #5985
When switching adaptar while live-streaming only first client stream continues
0%
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
Updated by r 2 almost 4 years 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.
Updated by r 2 almost 4 years 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.