Retries for LiveTV (IPTV)

[marleshi 0]

Hi all,

 

I am using Emby to record (DVR) what seems to be a rather unstable set of IPTV channels. The channels seem to be cutting in and out often during the day. I have found that my recordings normally bomb out with an error message:

 

SharedHttpPipelineSource: Give up retries copying live stream

 

The streams are mpeg-ts and I see that Emby directly records these (i.e. does not use ffmpeg), and that it retries the recordings a couple of times before giving up.

 

The question that I have is are there configuration parameters that control the retry behaviour? For example, could I retry 100 times instead of 2? Is there a parameter to introduce a delay between retries?

 

Ideally, one would be able to retry X times with Y seconds between successive retry attempts.

[Luke 37060]

Hi, there currently aren't any settings for that, but it's possible to add in the future. thanks.

[marleshi 0]

Hi Luke, thanks for the reply - I hope you can add this to your backlog at some stage.

[jbirmingham40 7]

I too would like to advocate for this.  My current provider can be unreliable at times and 2 retries in 5 minutes if often not enough to overcome this.  Would love to be able to bump this number.  Thanks.

[Luke 37060]

Hi, where did you get 2 retries in 5 minutes from?

[jbirmingham40 7]

Saw this in the log " The operation does not allow more than 2 retries within 00:05:00" and found this in the class SharedHttpPipelineSource.

 

Edited March 24, 2020 by softworkz
Removed code snippet

[softworkz 3335]

@@jbirmingham40 - Please don't post decompiled code in our forums

 

It's OK to discuss Emby's behavior, though. Emby allows:

• 2 disconnections within 5 minutes,
• 4 disconnections within 30 minutes, and
• 6 disconnections within 1 hour

This is not about 'retries' as you were suspecting, this is about how often an IPTV provider stops serving an established stream connection.

 

After that, Emby makes 7 attempts (this could be called 'retries') to re-establish a connection:

• Initial attempt
• after 1s
• after 4s
• after 8s
• after 16s
• after 30s
• after 60s
  => final failure

The allowed disconnections above are intentionally set to rather strict values. Those values are not even meant to provision for unreliable IPTV providers, instead they are intended to deal with all other kinds of conditions, e.g. network outage or daily DSL or Cable disconnection by the internet connection provider.

 

From our experience, IPTV providers that are unable to provide constant and reliable streams are typically rather of the non-professional kind (to say the least) and it's typically those kind of streams that are causing the most problems (e.g. inconsistent timestamps, incorrect stream information etc.)

 

In the future, we want to further improve our IPTV experience and this requires proper streams at the source side. So would highly recommend switching to a better IPTV provider.

[Spaceboy 2493]

So is this also the answer to this question?

 

 

Simultanious scheduled recordings

https://r.tapatalk.com/shareLink/topic?share_fid=77624&share_tid=81916&share_pid=860966&url=https%3A%2F%2Femby%2Emedia%2Fcommunity%2Findex%2Ephp%3F%2Ftopic%2F81916-Simultanious-scheduled-recordings%2Fpage__view__findpost__p__860966&share_type=t&link_source=app

Edited March 24, 2020 by Spaceboy

[jbirmingham40 7]

Roger on the code. Didn’t think I was sharing anything proprietary but will avoid posting in the future.

 

I understand the root cause is my provider. Was hoping to work around the reliability issues but realize this is a bandaid.

 

Will look for alternatives.

[softworkz 3335]

Roger on the code. Didn’t think I was sharing anything proprietary but will avoid posting in the future.

 

It's just that it shouldn't become a habit ;-)