Should v5 try to reconnect a scheduled recording?

[markn62]

I've been test driving NextPvr after being disappointed with the way TvMosaic handles interrupted recordings. Creates a lot of partials while recording an inherently less reliable IPTV source.  I'm finding NextPvr has the same struggle. But at least NextPvr doesn't seem to corrupt the .TS file after an interruption. It's a good test bed now since xcode recently blew up and providers are working to restore reliability in their feeds.

Curious, how NextPvr is designed to record.  For example, while watching an IPTV stream live and recording simultaneously I see a 10 second drop in the IPTV stream then it resumes.  I notice the recording stops in response to the dropped stream and never resumes recording.  Is v5 suppose to keep trying to reconnect the stream and then start a 2nd recording to finish the same programmed scheduled?  Or does it simply drop the recording and leave the user with one partial recording instead of two or more?  If the latter I would like to suggest a feature enhancement that would restart the recording so only the time the connection dropped is missing, even if it results in multiple partial recordings for one scheduled program.  Hope this is clear.

Is it possible?

[sub]

The behaviour varies a bit depending on if the source was an m3u8 or ts stream, and whether the stream was down at the time the recording was due to start.

If it was down when the recording was due to start, the recording will be marked as failed, with whatever error was returned (like 403 unavailable etc). In the case of the stream going down mid recording, and it's a TS stream, it's supposed to continue to try reconnecting, and when it manages to reconnect it'll just resume writing to the same .ts file. (you'll probably end up with a pretty crappy file if the IPTV stream went down though. ie, duration will probably report incorrectly in various players)

[markn62]

Source provides ts stream. Have yet to see NextPvr append onto an existing ts file after the source stream was briefly interrupted. I'll watch the log file and see if I can find this action.

[sub]

Actually thinking about it, I'm not 100% sure its the same in NextPVR v5. In v4 it'll reconnect and append to the existing file. I'd have to check it with v5 (which has a different implementation of this stuff vs v4). In theory it should have the same behaviour though, and if it's not, I'll fix it to behave that same way.

[markn62]

Thanks much! It's my biggest issue with recording Iptv, I rarely watch live. So it would be fantastic to see it work as you suggest.

[sub]

That's the worst thing about IPTV...streams/connections from the providers are just unreliable. If you're got connections going up and down, you're going to end up with some crap in your recordings, regardless of how the software behaves (after all, it can't work magic). Life is so much nicer with streams coming from devices, where you can generally rely on them working all the time.

[markn62]

Sure is. During the best of reliability I would get about 1 in 5 recordings corrupt. I was researching and find some suggestions that recording in ts format is not the best for this situation as it only indexes the start and end of the recording so it can get corrupted easily. I'll probably expose my ignorance on this topic but I thought perhaps if recordings could be stored in another container like mkv or mp4 that has indexing every so many seconds it might better survive a less than perfect source while recording to disk. Not sure all the implications of storing in other than ts. Or perhaps getting the source stream in HLS or RTMP may help, any thoughts on another stream type helping?

[sub]

.ts is the best storage format for live tv and recordings from live tv, because it has no indexes. It's just a copy of exactly what your broadcaster (or IPTV Provider in this case) sent. It was designed for digital tv, and is the universal standard used for all digital services (except the upcoming ATSC 3.0)

.mkv/.mp4 instead have indexes at the start of the file, that must be updated at completion of the recording. This has many downsides, including not being able to play recordings while they're in-progress. These are good standards for content authored from good pre-existing source material. They're not good live sources.

At the end of the day though, if your iptv connection goes down, or the provider restarts the encoder, or other numerous things they can do, you're going to have some crap in your file regardless of whether its .ts, .mp4, .mkv etc.

[sub]

For better quality recordings out of connections that go up and down, you may find benefit in remuxing in PostProcessing.bat (whether to .ts or .mp4 or .mkv)

[markn62]

Hmmm, I'll try that. Appreciate you expanding on this. Your explanation is most helpful. I appended a last minute thought on my post, you may have missed. Would perhaps getting the source stream in HLS or RTMP help or would it not improve recording reliability? I'm not even certain if NextPvr can handle these two alternate stream types.