marleshi 0 Posted October 16, 2019 Share Posted October 16, 2019 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. Link to comment Share on other sites More sharing options...
Luke 37272 Posted October 16, 2019 Share Posted October 16, 2019 Hi, there currently aren't any settings for that, but it's possible to add in the future. thanks. Link to comment Share on other sites More sharing options...
marleshi 0 Posted October 18, 2019 Author Share Posted October 18, 2019 Hi Luke, thanks for the reply - I hope you can add this to your backlog at some stage. Link to comment Share on other sites More sharing options...
jbirmingham40 7 Posted March 23, 2020 Share Posted March 23, 2020 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. Link to comment Share on other sites More sharing options...
Luke 37272 Posted March 23, 2020 Share Posted March 23, 2020 Hi, where did you get 2 retries in 5 minutes from? Link to comment Share on other sites More sharing options...
jbirmingham40 7 Posted March 24, 2020 Share Posted March 24, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
softworkz 3350 Posted March 24, 2020 Share Posted March 24, 2020 @@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. Link to comment Share on other sites More sharing options...
Spaceboy 2507 Posted March 24, 2020 Share Posted March 24, 2020 (edited) 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 1 Link to comment Share on other sites More sharing options...
jbirmingham40 7 Posted March 24, 2020 Share Posted March 24, 2020 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. 1 Link to comment Share on other sites More sharing options...
softworkz 3350 Posted March 25, 2020 Share Posted March 25, 2020 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 ;-) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now