Re-start recording for Live TV channel even if IPTV stopped working

[wtploiqbn 6]

Hi everyone

I was hoping anyone could help or have any advice on this:

I am using Emby Server premiere on a Win10, browser Firefox v106.0.3, I got a m3u playlist for IPTV.

I setup Schedule --> to record in the same time 2 different channels from the same m3u IPTV playlist:

1) channel #1 was recorded for about 30 mins, then it stopped all of a sudden

2) channel #2 was recorded for about 1hr+ up to the end, seemed it worked fine

The issue is that channel #1 just stopped like that, I did not do anything to it, I wasn't running any other apps in the background.
Channel #2 recorded all fine up to the end.

Is there any way for me to force Emby server to re-start the recording when it stops recording for a specific channel (ex: for channel #1)?
i.e. if channel #1 stopped recording (maybe a playback issue) then Emby could re-start the recording again from where it stopped, without me having to manually schedule it?

PS: if I go in manually and schedule again channel #1, it just works, thus I was hoping that I can set this up automatically instead of keeping an eye for hours on a channel if it stops recording : (

Thank you! 

Edited November 1, 2022 by wtploiqbn

[Abobader 2942]

Hello wtploiqbn,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 37050]

Hi there, can you please attach the emby server log from when this happened? When it stops it does try again, so it's possible the re-opening of the stream failed.

How to Report a Problem

Thanks.

[Spaceboy 2493]

19 hours ago, Luke said:

Hi there, can you please attach the emby server log from when this happened? When it stops it does try again, so it's possible the re-opening of the stream failed.

How to Report a Problem

Thanks.

can you confirm how long after it stops does it retry and then how many times after that please?

[Spaceboy 2493]

@Luke ?

[wtploiqbn 6]

hey guys, sorry for the late reply, got sidetracked.

I will replicate the issue in the next few days and will post the emby server log here.

thank you!

[Luke 37050]

13 hours ago, wtploiqbn said:

hey guys, sorry for the late reply, got sidetracked.

I will replicate the issue in the next few days and will post the emby server log here.

thank you!

That would be great, thanks !

[Spaceboy 2493]

On 02/11/2022 at 19:41, Spaceboy said:

can you confirm how long after it stops does it retry and then how many times after that please?

@Luke can you clarify please?

[wtploiqbn 6]

hey guys

Quote

Luke:
Hi there, can you please attach the emby server log from when this happened? When it stops it does try again, so it's possible the re-opening of the stream failed.

It did not seem to try again, it seemed that it just stopped and did not record anymore.

Quote

Spaceboy:
can you confirm how long after it stops does it retry and then how many times after that please?

Usually it stopped at around 30 mins mark, but i had it at around 20 mins as well; it varied but usually was around the 30mins.

It stopped maybe every 2nd time after from what I recall.

I tried to replicate the error guys, but did not manage to replicate it, I will post here in the next few days if I manage to, still testing.

Let me give more info on the issue:

- i use a m3u playlist that I just add in the settings at Live TV
- i always try to use the lower version of it (SD instead of HD)
- PC i use is connected through Wi-Fi

What I think was happening is that I was trying to record these 2 different channels from the same playlist; I mean the m3u file that i import in Live TV > Settings uses a streaming URL, and it has lots of channels inside it. My wild guess is that because I am trying to run 2 different channels from the same streaming URL, maybe that puts a limit on the playback and thus not working fine and stops one of the recordings (for channel 1).

So in the meantime I did another test, I only used 1 x Channel recorded at a time, so did not use 2 different channels in the same time. ----> this method worked beautifully and was able to record without any issue, 99% of the cases it worked just fine. I  also updated the m3u file constantly, deleted it from Live TV > Settings, and imported a new fresh version of it --- > this seems that it helped (I think).

I will try to record 2 different channels in the same time and post here the server log. 

Sorry for the delayed reply, did not get the chance to test it properly.

 

[Luke 37050]

3 hours ago, wtploiqbn said:

hey guys

It did not seem to try again, it seemed that it just stopped and did not record anymore.

Usually it stopped at around 30 mins mark, but i had it at around 20 mins as well; it varied but usually was around the 30mins.

It stopped maybe every 2nd time after from what I recall.

I tried to replicate the error guys, but did not manage to replicate it, I will post here in the next few days if I manage to, still testing.

Let me give more info on the issue:

- i use a m3u playlist that I just add in the settings at Live TV
- i always try to use the lower version of it (SD instead of HD)
- PC i use is connected through Wi-Fi

What I think was happening is that I was trying to record these 2 different channels from the same playlist; I mean the m3u file that i import in Live TV > Settings uses a streaming URL, and it has lots of channels inside it. My wild guess is that because I am trying to run 2 different channels from the same streaming URL, maybe that puts a limit on the playback and thus not working fine and stops one of the recordings (for channel 1).

So in the meantime I did another test, I only used 1 x Channel recorded at a time, so did not use 2 different channels in the same time. ----> this method worked beautifully and was able to record without any issue, 99% of the cases it worked just fine. I  also updated the m3u file constantly, deleted it from Live TV > Settings, and imported a new fresh version of it --- > this seems that it helped (I think).

I will try to record 2 different channels in the same time and post here the server log. 

Sorry for the delayed reply, did not get the chance to test it properly.

 

Hi,yes that would be great, please attach the emby server log from an example. Thanks.

[Spaceboy 2493]

On 14/11/2022 at 22:22, Spaceboy said:

@ Luke can you clarify please?

@Luke a quick answer here would be appreciated. its pretty critical to the point at hand

[softworkz 3335]

On 11/18/2022 at 8:10 PM, Spaceboy said:

@Luke a quick answer here would be appreciated. its pretty critical to the point at hand

The basic retry pattern on all kinds of connection setup errors and network errors is this: 1s, 4s, 8s, 16s, 30s, 60s => shutdown 

When there's no ip connection at all or the remote host cannot be resolved, then each connection attempt will error out quickly, then this adds to 119s.
But usually, each connection attempt takes quite a while until it fails, it could easily go over > 5 minutes.

On top of this, we have a second level of connection observation. This limits the number of server-side disconnects over time. It doesn't count network or connection errors, but solely the case where the remote server explicitly closes the connection. Sometimes, this can happen due to a failure on a provider's server. But when it happens more frequently within a given amount of time, then it can be taken for almost granted that the server is disconnecting for a reason, which is in most cases that users are exceeding their limit of simultaneous streams. This can be for multiple reasons:

• The user is simply using more simultaneous streams than the account allows
• The credentials have been compromised and are being used by others at the same time
• Or one is using pirated credentials themselves

@wtploiqbn - in your case it's very likely the first bullet. In the other cases, you wouldn't have been able to record a single stream.

Please check back with your provider, how many simultaneous streams are allowed for your account. I guess it's 1

The reason why it doesn't stop immediately is due to the (moderate) retries that Emby is doing and the fact that providers evaluate and exchange stream usage metrics with delay - partially by intention, because they don't want to create a bad experience for users playing around - partially for technical reasons.
The bad side is that it's not quickly clear what's happening, given that the two streams were running parallel for quite a while, so you might at first think that two streams would be working.

If you like, you could try to do 4 simultaneous recordings. If my assumptions are right, these will error out more quickly.

[Spaceboy 2493]

On 20/11/2022 at 21:07, softworkz said:

The basic retry pattern on all kinds of connection setup errors and network errors is this: 1s, 4s, 8s, 16s, 30s, 60s => shutdown 

When there's no ip connection at all or the remote host cannot be resolved, then each connection attempt will error out quickly, then this adds to 119s.
But usually, each connection attempt takes quite a while until it fails, it could easily go over > 5 minutes.

On top of this, we have a second level of connection observation. This limits the number of server-side disconnects over time. It doesn't count network or connection errors, but solely the case where the remote server explicitly closes the connection. Sometimes, this can happen due to a failure on a provider's server. But when it happens more frequently within a given amount of time, then it can be taken for almost granted that the server is disconnecting for a reason, which is in most cases that users are exceeding their limit of simultaneous streams. This can be for multiple reasons:

• The user is simply using more simultaneous streams than the account allows
• The credentials have been compromised and are being used by others at the same time
• Or one is using pirated credentials themselves

@wtploiqbn  - in your case it's very likely the first bullet. In the other cases, you wouldn't have been able to record a single stream.

Please check back with your provider, how many simultaneous streams are allowed for your account. I guess it's 1

The reason why it doesn't stop immediately is due to the (moderate) retries that Emby is doing and the fact that providers evaluate and exchange stream usage metrics with delay - partially by intention, because they don't want to create a bad experience for users playing around - partially for technical reasons.
The bad side is that it's not quickly clear what's happening, given that the two streams were running parallel for quite a while, so you might at first think that two streams would be working.

If you like, you could try to do 4 simultaneous recordings. If my assumptions are right, these will error out more quickly.

thanks softworks, clear explanation. does the retry create a new recording or does the original continue with a skip in the video/audio while its out?

[Luke 37050]

13 minutes ago, Spaceboy said:

thanks softworks, clear explanation. does the retry create a new recording or does the original continue with a skip in the video/audio while its out?

A little of both actually. It will try to recover within the same stream, and if that happens it will append to the same file. If that fails, then the recording scheduler will have it try again a minute later.

[softworkz 3335]

1 hour ago, Spaceboy said:

thanks softworks, clear explanation. does the retry create a new recording or does the original continue with a skip in the video/audio while its out?

What I have described above is all within the context of a single playback or recording and will write to the same file. That can be with a discontinuity or even overlap (when the retry starts at a time that was already received). The timings are attempted to be sanitized, which works within certain constraints, fairly well.

What Luke mentioned (recording scheduler) is one level above and creates a new file. At this point, it makes no sense to try and append to the previous recording, because that's out of the context withing the timing correction can work.

[wtploiqbn 6]

On 21/11/2022 at 08:07, softworkz said:

The user is simply using more simultaneous streams than the account allows

hey guys

yes, I think this is the case for me. I tried to replicate the error but was not able to. Thus, what I did is schedule recording from only one channel from the m3u playlist; so far it has been working great.

Everytime I would add 2 or 3 channels extra to record from same m3u playlist that has same streaming server, it seemed to crash and not record all the channels. From what I looked into it, it seems that the channels are working best if played one channel at a time.

Quote

If you like, you could try to do 4 simultaneous recordings. If my assumptions are right, these will error out more quickly.

Yes i tried this in the past and it crashed faster, agree.

Quote

What Luke mentioned (recording scheduler) is one level above and creates a new file. At this point, it makes no sense to try and append to the previous recording, because that's out of the context withing the timing correction can work.

Agree with this, yep, they should be separate recordings.

Thanks a lot guys, I can't stress enough how awesome support you have, I am beyond impressed! You've all been super helpful and gave me very clear explanations, thank you!

The issue that I have is that the streaming provider limits connections most likely. Since I first asked you guys, I tried to record only 1 x channel at a time, and it works just beaufully nice, no error.

Thank you once again!

[iiiJoe 55]

18 minutes ago, wtploiqbn said:

Thanks a lot guys, I can't stress enough how awesome support you have, I am beyond impressed! You've all been super helpful and gave me very clear explanations, thank you!

Hard agree on the above!!