Tvheadend

I've noticed that a recording that did work off the same stream shows:

2018-07-09 13:00:00.386 [   INFO]:dvr:  #  type              lang  resolution  aspect ratio  sample rate  channels
2018-07-09 13:00:00.386 [   INFO]:dvr:  1  HEVC                    1280x736    40:23
2018-07-09 13:00:00.386 [   INFO]:dvr:  2  AC3               spa                             48000        2

Gman,
I have had the same issue. At the time didn't pay too much attention to what I did to fix it. As i just wanted to setup recording. Although the issue does still occur, it happens less now.

For ts streams, i don't use an ffmpeg pipe, the url is straight as the m3u url comes. For mkv/mp4 stream urls i use
pipe:///bin/ffmpeg -i http://STREAMURL -map 0 -codec copy -metadata service_provider=IPTVProvider -metadata service_name="UK: Sky Cinema Premiere HD" -f mpegts pipe:1

I have only ever noticed this issue when recording using an ffmpeg pipe command, not a direct ts stream url. When i adjusted my recording profile to .ts and not mkv, I have since not noticed the problem any where near as often now.

Without actually confirming, I put the issue down to tvheadend running on a small nas (synology DS213J) with not enough CPU/RAM to process.

I have seen this happen from time to time with .ts streams, both when recording and when playing live. It seems quite hit & miss - when playing a live stream, stopping & restarting will often result in a video stream as expected.

I have never seen it happen with .m3u8 URLs piped via ffmpeg.

Thanks Jon/Hiro for your feedback.

Jon: I've just modified my m3u file so that .ts streams are just the URL, and anything else goes via ffmpeg and just clicking around channels I've found a few that don't work the first time (I see "No input detected" in the tvh log), so I switch channels and come back to it and it starts up fine Just curious what do you use for your stream profile in recording settings? matroska?

Hiro: it's a shame because if I leave anything to record, it's a hit & miss whether it'll actually work or not. I'm truly curious how anyone else is able to reliably record things off IPTV streams (specifically .ts) in tvh. If the issue is hardware related (since the Synology NAS is not exactly a powerful machine), I'm happy to throw hardware at the issue but I'm not convinced it's hardware.

Well I've just found that a recording with with .m3u8 URL piped via ffmpeg has done this today 8-(
I'm recording with mkv, but I don't think the recording profile is the issue though - I've had this happen with reasonable frequency when streaming via Kodi, and that's using the htsp profile.

I'm running TVH on a Pi 2 BTW.

G man wrote:

Thanks Jon/Hiro for your feedback.

Jon: I've just modified my m3u file so that .ts streams are just the URL, and anything else goes via ffmpeg and just clicking around channels I've found a few that don't work the first time (I see "No input detected" in the tvh log), so I switch channels and come back to it and it starts up fine Just curious what do you use for your stream profile in recording settings? matroska?

Hiro: it's a shame because if I leave anything to record, it's a hit & miss whether it'll actually work or not. I'm truly curious how anyone else is able to reliably record things off IPTV streams (specifically .ts) in tvh. If the issue is hardware related (since the Synology NAS is not exactly a powerful machine), I'm happy to throw hardware at the issue but I'm not convinced it's hardware.

My recording profile is the default (mkv) with only dvr and file retention being different. My second recording profile is ts passthrough.

I also have the same issue sometimes with the channel switch where there is no input detected and restarting the channel works This was easy to diagnose, as on my internet gateway (pfsense) I can watch the bandwidth coming in. When a stream started (only some channels) there appeared to be little to no traffic coming in, after approx 10 seconds then the channel would work and the bandwidth would match the bitrate of the stream (12-16MB/s). I put this down to the stream taking a while to navigate it's way accross the internet. This issue for me is not isolated to tvheadend, as the same would occur on VLC.
I wonder could this be fixed by getting tvheadend to buffer first before passing to the endpoint?

Gman, noting you also have a synology, have you removed the universal search app? As that synology forced app is a resource hog and I had heaps of issues with it consuming over 80% of cpu when it was on and not even indexing. Removing it and my system returned to dsm 5 performance.

Doing a forum search for 'only audio' shows this issue has been around for a year or more. Looks like there might be a fix in 4.3, but not in any stable build as yet. I might try building 4.3 and see if it's any better.

I went ahead and installed 4.3 in the hope of fixing this issue.

Unfortunately I've just had 2 recordings [1 yesterday & 1 today] fail in this way, so it looks like 4.3 isn't the answer.

I was having issues with IPTV on my pi 3b+. Ive now switch to an alternate (paid) product which works fine.

Jon, thanks for the suggestion to turn off the universal search app. I just turned it off.

So it looks like we're all having issues reliably recording off IPTV streams :-(

Gary: just curious what alternate product did you switch to?

Tv mosaic. There is a 30 day trial so you can give it as go without committing. Very easy to setup too no need to pipe things. I use mrmc as the front end.

I switched the stream profile of my IPTV recording profile from Matroska to pass, and so far, haven't had a repeat of the problem.

Progress so far: Using the 'pass' stream profile does seem to solve the problem of getting audio-only recordings, or video with strange aspect ratios.

The other problem I had was a couple of channels that would almost always quit partway through a recording. Both of these were .ts URL's so weren't piped at all. Neither were particularly hi-res, so bandwidth wasn't an issue. I got the same problem when I got the channels via an alternate provider.

I've updated both of these channels to use the script here: https://tvheadend.org/issues/3885;#note-4

So far, I've not has any failures.