Recordings cut off

[tvgenie]

Hi all,

First off, thanks for providing this free PVR solution! I am having a few issues that I hope can be resolved on my end. I have tried tvheadend and piping through ffmpeg and any other software I can find to record IPTV events in their entirety. The issue is (I think) that when the stream stutters, the recordings get all messed up. Either they start over, or just plain stop. Today I tried a 4 hr recording and the UI said it was recording the entire way through as scheduled, the the end file only ended up being 6 mins long or so and ~300 mb in size.

Is there anything I can try to resolve this issue so that if the stream stutters, the recording will continue and not stall or get corrupted? Thanks!

Logs attached. Recording of Peacock 1 started at 15:00 and was scheduled to end at 19:00 on 8/4/2022. Only ran for about 6 mins though as I noted above. Running the more recent install (I assume) on a Raspberry Pi 4.

[sub]

You're using .ts streams from your IPTV provider. Most also provide .m3u8 streams. Might be worth trying this to see if it makes siginficant a difference.

Otherwise, the next build is slightly better at recovering when a ts connection is randomly disconnected.

Ultimately we're at the mercy of the IPTV service though...and it's pretty common for these types of services to be superficially ok, but can't be relied on for a full hour or so.

[tvgenie]

You're using .ts streams from your IPTV provider. Most also provide .m3u8 streams. Might be worth trying this to see if it makes siginficant a difference.

Otherwise, the next build is slightly better at recovering when a ts connection is randomly disconnected.

Ultimately we're at the mercy of the IPTV service though...and it's pretty common for these types of services to be superficially ok, but can't be relied on for a full hour or so.

Thank you sub, I will try that. If you have a moment, is there an easy way to swap my m3u file to change to HLS streams? I will reach out to the IPTV support as well but not sure how long it will take for a response.

[sub]

It depends on the service. Some of them have urls with "output=ts" in the url, and it's just a matter of changing that bit to "output=hls" or "output=m3u8"

[tvgenie]

It depends on the service. Some of them have urls with "output=ts" in the url, and it's just a matter of changing that bit to "output=hls" or "output=m3u8"

Bingo, you're right. Thanks!

[tvgenie]

It depends on the service. Some of them have urls with "output=ts" in the url, and it's just a matter of changing that bit to "output=hls" or "output=m3u8"

So far, holding strong. 4 hour recording hasn't faltered yet. Curious, what causes the hls stream to be able to recover so much better? Thanks again.

[sub]

Curious, what causes the hls stream to be able to recover so much better?

ts is a single connection that has to stay connected.

hls is just a series of small files sitting on their web server, so the application using lots of connections for short period of time to download these small files..ie, so not dependent on their connection staying up for extended periods of time.

[tvgenie]

Curious, what causes the hls stream to be able to recover so much better?

ts is a single connection that has to stay connected.

hls is just a series of small files sitting on their web server, so the application using lots of connections for short period of time to download these small files..ie, so not dependent on their connection staying up for extended periods of time.

Interesting...so does that mean if my provider allows 5 connections max, I need to set the "allowed connections" in device settings to 5 (right now its at 2) and maybe even consider upgrading to more connections from my provider?

[sub]

Downloading a hls stream, it'd usually only be downloading one file at a time, so it'll only be one connection as such. The difference is more that it's lots of short lived connections for hls, rather than one long lived connection.

[tvgenie]

Downloading a hls stream, it'd usually only be downloading one file at a time, so it'll only be one connection as such. The difference is more that it's lots of short lived connections for hls, rather than one long lived connection.

I see, thank you. We can mark this thread closed and resolved then. After swapping to HLS from TS I ran concurrent recordings of an event today to test: one with TVH and one with NextPVR and TVH experienced 30+ data recording errors while NextPVR is still going strong. Thanks again so much for what you've done. Bought both iOS and tvOS apps to support.