Automatically restart IPTV streams on drop out?

[JP23]

Hi,

Recording from IPTV sources can be quite hit and miss. I've had 3 or 4 hour long recordings that are flawless, but I've also often found that I only ended up with the first 15 minutes - presumably because the stream drops out.

Would it be possible to have NPVR re-initialize the stream if no data is received for x seconds?
Perhaps the recording could continue in a second file like it does it there's a recording service restart.

[JP23]

Hi Sub if you're reading this - I would like some clarification please.

Does NPVR currently attempt to restart a stream if data stops being received?

If not - is there any prospect of you implementing anything like this?

If the answer is no then I will look for other solutions.

[sub]

Yes, it does try to reconnect when a IPTV stream goes down. We'd probably need to do some diagnostic work to understand in more detail what you're seeing. It's not uncommon for non-legit IPTV streams to go down for an hour or two though, and when that happens there isn't anything NextPVR can do about it.

Are you using .ts or .m3u8 streams? Most IPTV providers provide both, and they'll have slightly different characteristics. When everything is going well, the .ts streams are a long-lived single connection (though will try to reconnect if lost), and .m3u8 streams are thousands of short-live connections (downloading small .ts files).

[JP23]

Thanks for your reply.

Would you mind describing how it works in a bit more detail? Does NPVR just reconnect if there's no data received for a certain number of seconds? Are there any limitations on how many times or for how long it attempts to reconnect?
Will the reconnection attempts show up in the logs, and if yes is there any keyword to look out for or search for?

Also, if I have a choice, do you recommend .ts or .m3u8 for recording purposes?

[sub]

Would you mind describing how it works in a bit more detail? Does NPVR just reconnect if there's no data received for a certain number of seconds? Are there any limitations on how many times or for how long it attempts to reconnect?
Will the reconnection attempts show up in the logs, and if yes is there any keyword to look out for or search for?

In the case of .ts, it'll reconnect if the connection is dropped. For .m3u8, it's in a continuous cycle of requesting a .m3u8 file, then a .ts file, and I think it just continues to try regardless of whether the last attempt files. I can't really remember precisely whether it'll eventually stop trying, and unfortunately I'm really busy with day-job stuff right now, so can't look into it for the next few days.

For both types of stream, if it can't connect at recording start time, it'll give up and the recording be marked as an failed, and the reason noted.

For errors mid recording - in the case of m3u8 you'll see errors in the nrecord.log. In the case of .ts, if it disconnects mid recording, it'll try reconnecting - this isn't in the normal logs, but there is some extended logging that can be enabled to see it (but it produces massive log files)

Also, if I have a choice, do you recommend .ts or .m3u8 for recording purposes?

I don't really have a preference, but you may find one works better than the other with your IPTV provider, so probably best to try both.