Tvheadend

I wonder how self-isolation affects people's knowledge.
ATSC standard is used not only in US aka USA, but also in Canada (on Nord some of them are French speaking)
and in Mexico (Spanish speaking)

this is a coverage map ;)

Around is writhing another user K Shea
freetoairamerica.wordpress.com
With also not make difference between Nord and South America, with are different continents.

Advertising outside sources is not so good idea,
there is enough space in this forum for this.
Suggestions is accepted also https://tvheadend.org/boards/5/topics/29237

Certainly, the blog posts could be titled 'mostly for North American users', but that's not really the point.

Whether because of self-isolation or simply because the average American doesn't even know what ATSC is, most are not aware there is a possibility outside of paying the cable company and using whatever sub-par equipment they provide. Tvheadend and the other tools described in my posts provide another option. That is the point of the posts, although I wouldn't be unhappy if they were helpful to people outside of the US.

The original intention of the posts was/is to document how Tvheadend and node-ffmpeg-mpegts-proxy can be used to replace the MythTV + HD-PVR setup that has been the only Kodi back-end option for some users. In searching the Tvheadend forums and irc logs, I found a number of instances of people asking whether Tvheadend would work with HD-PVR, IR blasters, etc. There were no positive responses. I'm now running such a set up and thought other people might benefit from documentation describing how the system is installed and configured.

saen acro wrote:

freetoairamerica.wordpress.com
With also not make difference between Nord and South America, with are different continents.

Actually the article you may have in mind is:

The never final, always subject to revision article on how to build a Satellite TV PVR distribution system using Tvheadend
https://freetoairamerica.wordpress.com/2016/11/24/the-never-final-always-subject-to-revision-article-on-how-to-build-a-satellite-tv-pvr-distribution-system-using-tvheadend/

Although it's primarily about free-to-air satellite reception in North America it does also mention the use of a HDHomeRun device.

I would guess that the reason that site probably doesn't go out of its way to distinguish between North and South America is probably because satellite footprints can cover parts of both continents.

I only briefly skimmed Jerry Fath's blog but from what I have seen so far I would hesitate to recommend it. For example, he does not even mention that U.S. and Canadian schedule data can be obtained for free by using zap2xml (http://zap2xml.hosterbox.net/). And I do know that you can create a system that replaces MythTV without using this node-ffmpeg-mpegts-proxy program that he talks about. The best I can make of his articles is he's trying to marry a cable TV set-top box to Tvheadend, but why would anyone want to do that in the first place? More and more people are becoming "cord cutters" (a term for people who drop their cable TV subscriptions), due to the extremely high prices and forced bundles, and cable boxes in North America are notorious power hogs, drawing more electricity than a refrigerator. And most cable boxes these days have built-in PVR capability, so I guess I don't get the point.

I guess we'll have to how the series continues but at first glance I left feeling more confused than anything.

Sean, thanks for the reply. That's exactly the kind of input I need.

I didn't know about zap2xml. I've been using Schedules Direct for years. I'll have a look and see how to integrate the information. Free is good.

Without the node-ffmpeg-mpegts-proxy program, there is no hook to allow an IR blaster to change channels before live streaming. The Pre processor command provided through Tvheadend works for recording, but is not called before live streaming begins. Am I missing another method that you know about?

I agree that many people are ditching their set-top-boxes. The problem is that there are still channels (eg ESPN) that aren't available over-the-air and many of the new streaming subscriptions such as DirectTV Now still lack features (DVR, decent program guide) found with traditional cable.

As to why you would want to marry a set-top-box to Tvheadend:
The cable box interface is terrible - giant ads, un-intuitive interface, etc.
Many people are already using Kodi for streaming of local video libraries. This method provides an integrated interface that my family enjoys.
Cable box rental averages $10 / month / box here. Another $10 / month for a whole house DVR box. I have 6 TVs scattered around the house, but no more than two are in use at any given time. Monthly STB rental savings = $40 + $10 for losing the DVR. Also saves power cost of 4 STBs, though admittedly, some is given back to the Tvheadend machine.

Thanks again for the feedback. The guides definitely won't be for everyone, but I'd like to make them as useful as possible.

Why do you need the node-ffmpeg-mpegts-proxy program? Tvheadend can handle converting a stream, all you need to do is make sure that you have ffmpeg installed on your system, such as one of the ffmpeg static builds from https://johnvansickle.com/ffmpeg/

Then you use the pipe:// syntax in your Mux. For example:

pipe://ffmpeg -loglevel fatal -fflags +genpts -i http://192.168.1.100:8080/hdmi -c copy -flags +global_header -strict -2 -metadata service_provider=Capture -metadata service_name=Capture -f mpegts pipe:1

Replace http://192.168.1.100:8080/hdmi with the address and port of your card's stream. Replace "Capture" with whatever you want, but no spaces.

Also in the Mux creation set the Mux Name to whatever you want. Once you have done that, the stream from the capture device should scan in just as if it were a stream from a tuner. It may actually show two streams, only the lowest numbered one has the video.

I just don't see the point of adding node-ffmpeg-mpegts-proxy in this setup, it appears to be just an extra layer of complication, unless I'm not seeing something. The text isn't real clear.

By the way, the web interface for your card may indicate that the frame rate can only be set to a value between 5 and 30 frames per second, but it will actually accept 60 as well, and 60 yields smoother output.

EDIT: I started writing this before you posted your most recent reply, so didn't see the part about changing channels. You're using an IR blaster to change the channel on the cable box, that's interesting. I wonder if the same technique could be used to select channel and program on other types of STB's, such as streaming devices? Probably not because in most cases that's not a live stream; you need to select an actual program to watch.

Jerry Fath wrote:

Sean, thanks for the reply. That's exactly the kind of input I need.

I didn't know about zap2xml. I've been using Schedules Direct for years. I'll have a look and see how to integrate the information. Free is good.

Take a look at https://freetoairamerica.wordpress.com/2014/12/03/some-hints-for-getting-free-to-air-satellite-channels-into-the-electronic-program-guide-in-kodi-or-xbmc-or-another-frontend/ which may help you. There are some additional links near the bottom of that article.

Without the node-ffmpeg-mpegts-proxy program, there is no hook to allow an IR blaster to change channels before live streaming. The Pre processor command provided through Tvheadend works for recording, but is not called before live streaming begins. Am I missing another method that you know about?

Not offhand but then it's not something I've ever attempted to so, since I'm not a cable subscriber.

I agree that many people are ditching their set-top-boxes. The problem is that there are still channels (eg ESPN) that aren't available over-the-air and many of the new streaming subscriptions such as DirectTV Now still lack features (DVR, decent program guide) found with traditional cable.

As increasing numbers of people become cord cutters, I think that will change. The move to getting content off the Internet is still a relatively new phenomena, at least as far as the general public is concerned.

As to why you would want to marry a set-top-box to Tvheadend:
The cable box interface is terrible - giant ads, un-intuitive interface, etc.
Many people are already using Kodi for streaming of local video libraries. This method provides an integrated interface that my family enjoys.
Cable box rental averages $10 / month / box here. Another $10 / month for a whole house DVR box. I have 6 TVs scattered around the house, but no more than two are in use at any given time. Monthly STB rental savings = $40 + $10 for losing the DVR. Also saves power cost of 4 STBs, though admittedly, some is given back to the Tvheadend machine.

Those are sound reasons, particularly if you can reduce the number of power-hungry STBs.

Thanks again for the feedback. The guides definitely won't be for everyone, but I'd like to make them as useful as possible.

I just think it might be helpful if you didn't front-load your explanatory text at the beginning and instead treated each post more like a stand-alone article, so that the explanations are followed directly by the screenshots. It's just hard to get the big picture when there is this wall of text in the first article and then all the screenshots are in the successive articles. I didn't even understand what you were trying to accomplish until I had jumped around a few times.

Yes, it seems Tvheadend is very close to being able to handle the channel change without an extra layer. I was using the pipe handler initially then realized the problem with live streams. I had forked the Tvheadend source code and was looking at patching in code to fire an event string to a unix socket opened externally by an event handler process. I think that would have worked, but this was a zero-code-change method and I see almost no CPU impact when running through the proxy.

Thanks for the tip on frame rates. I actually read about the 60 fps capabilities in a post on the MythTV wiki where they were describing how to use an HDMI encoder in MythTV. I started there, but the Tvheadend interface is so much nicer and the application is so much lighter weight. MythTV is powerful, but it requires MySQL (or MariaDB) and Apache for the web interface.

My use case is unusual, but both MythTV and MediaPortal have explicit support for the Hauppauge HD-PVR and there's really no reason to support that device other than for bringing video in from an STB. Given that, I thought it was worth documenting how to accomplish the same thing with Tvheadend.

Sean Micklem wrote:

I just think it might be helpful if you didn't front-load your explanatory text at the beginning and instead treated each post more like a stand-alone article, so that the explanations are followed directly by the screenshots. It's just hard to get the big picture when there is this wall of text in the first article and then all the screenshots are in the successive articles. I didn't even understand what you were trying to accomplish until I had jumped around a few times.

Excellent point. I'm aware that the organization isn't particularly good and it's hard to figure out exactly what I'm trying to accomplish. It's kind of a brain dump at this point - I wanted to get the walk-throughs down while I could still remember the steps from my own setup, but I'll spend some time thinking about re-organization.

I've been reading up on zap2xml since your reply. Can't believe I didn't know about it. My xmltv -> m3u converter script probably makes some assumptions it shouldn't about the format and order of the xml data, so I'm going to get zap2xml configured and make sure the converter works with xml files produced with data from either source.

Thanks again.

I got to thinking about the need to change the channel before starting the stream. Above I mentioned the pipe command:

pipe://ffmpeg -loglevel fatal -fflags +genpts -i http://192.168.1.100:8080/hdmi -c copy -flags +global_header -strict -2 -metadata service_provider=Capture -metadata service_name=Capture -f mpegts pipe:1

It occurs to me that everything after the pipe:// is simply running the ffmpeg program and receiving the output. In Linux, at least at the command line, you can stack commands using the && connector. For example a lot of Linux users will do something like sudo apt update && sudo apt upgrade to upgrade their systems. As I understand it, the && means that if the first command executed successfully, execute the second one.

So just maybe you could do something like this:

pipe://channel_change_script.sh channelnumber && ffmpeg -loglevel fatal -fflags +genpts -i http://192.168.1.100:8080/hdmi -c copy -flags +global_header -strict -2 -metadata service_provider=Capture -metadata service_name=Capture -f mpegts pipe:1

So that when the pipe command executes, in theory it would first run your channel change script and change to the specified channelnumber (replace with actual channel number), then if that's successful, start ffmpeg and capture the stream. The channel change script could be in whatever language you prefer, as long as the script will run from a Linux command prompt. You might need to specify a path to the script, as in pipe:///path/to/script/channel_change_script.sh and you'd probably want to use a different name for the script but you hopefully get the idea. IF this will work, and I don't know if it will or not, you could have a separate mux for each channel you want to receive and only change the channel number in the pipe command. There may also be a way to use a single mux for all channels and pass the channel number to the script some other way (maybe an environment variable or even a temporary file), there would only need to be some way for your script to know which channel you want to tune to.

This is all theoretical because I have no way to test this. What I'd be far more interested in is a way to do this with a streaming box (something that receives tv shows from the Internet), but most such boxes don't deliver a live stream but instead have apps which in turn have their own menus that allow you to select specific shows to view. Navigating those menus is relatively easy for a human, but would be impossible for any script because the script can't read what the screen is displaying and respond accordingly. On the plus side you would not need to use an IR blaster, since some of those boxes have control interfaces so that you can use external programs such as a phone app to control them, and you wouldn't be powering a cable box, and you wouldn't have scheduling conflicts because two shows you want to watch are both on at the same time on different channels. While it would be relatively easy to set up a streaming box as a live TV source, and only slightly more difficult to use a universal remote to select a show you want to watch, it would be impossible with any technology that I'm aware of to somehow automate the process of recording show X from network Y as soon as a new episode becomes available. The other problem is that many of those apps still require a pay TV login of some kind, so you'd still have to be a subscriber to cable or small-dish satellite, or a streaming service that gives you a login that will work with those channels, before you can even view the desirable content on those channels.

Interesting.

I'll have a go at stacking the channel change script inside the pipe handler. That would certainly be more efficient and less complicated to configure and document.

Well the only way you can capture dvbs signals in USA is with genpix sky walker. Is the only dvbs card 8psk turbo for win or unix but are discontinue or you can use dreamlink t6.