I have an old (original?) HD Homerun box with two tuners inside. Can Channels record more than one program per tuner?
i.e., depending on scheduling, can Channels record four programs simultaneously on my dual tuner HD Homerun box?
No, only one program per tuner can be recorded by Channels DVR.
That's a shame 
Are there any plans to support more than one program per tuner?
It is not a priority for us at the moment. The newer tuners use HTTP for streaming, which is much more reliable but its even harder to record multiple programs with that API. You can buy one of the new 4 tuner models and use both together for a total of 6 tuners.
How would you possibly record more than one program per tuner? Isn't the tuner "tuning" into the station you are wanting to record? I have two quatro HDHRs and that allows me to record or watch up to 8 channels, but not getting how it would be possible to do more than 8 programs when I only have 8 tuners.
You can record subchannels for ex. 2.1 2.2 2.3 of the same tuner. NEXTPVR and others do it.
Multi-Record on certain types of digital sources. This can allow you to watch/ record more than 1 show from a single source mux/frequency and so allows recording multiple shows at once from single tuner devices. You can always watch a currently recording program from the Recordings screen .
I didn't know that was possible... surprising.
In the UK and many parts of Europe (and elsewhere?), a terrestrial broadcast frequency isn't allocated to a single broadcaster as it is in the US. Here a single frequency or 'mux' can have as many as 30 services on it, so being able to record multiple programmes/streams from a single tuner would be a big bonus.
Tvheadend works like this by tuning to the entire mux and pulling out the service(s) it needs, but it's a bit tricky to implement as @tmm1 mentioned. Channels would need to know (or have an interface to tell it) which services are on which mux and all the PIDs (the video/audio/subtitle steam IDs) for each service.
You might be able to do it through an M3U instead of having Channels directly accessing your HDHR, but I don't know how the URLs would need to be crafted.
1 Like
An option is to use Tvheadend, and use it as an intermediary. That way you can get the full mux, but Channels will handle the recording while TVH takes care of handling the hardware/tuners.
1 Like
So a tuner demuxes all the muxed channels on a given individual frequency? And the only thing needed is the stream recording application to be able to individually record these demuxed channels. Wow, you learn something new every day.
2 Likes
Sort of. The HDHR tunes to the frequency of the mux and can 'see' everything on it. The difference is in the software communicating with the HDHR. In normal operation the HDHR does a channel scan and stores for itself what services are on each frequency/mux (eg, 'channel X' is on the mux at XXX MHz). When Channels sends a request for a particular service (tune to 'channel X'), the HDHR knows exactly what to send from the mux on XXX MHz instead of sending everything.
In contrast, tvheadend tells the HDHR to tune to XXX MHz and send it the entire mux, and tvheadend decides what to extract ('channel X' and maybe also 'channel G' and 'channel B'). That's why tvheadend can record multiple streams from a single tuner (if those services are on the same mux of course). But tvheadend needs to know for itself what services live on each mux instead of relying on the HDHR to know that.
2 Likes
That's mostly true. For some devices that may be how TVH works; for HDHR tuners it's a little different. HDHR tuners actually have PID filtering on the device. So, to reduce bandwidth, TVH tells the HDHR which programs it wants to receive—all of them, or just 'X' and 'B', or maybe just 'G'—and the HDHR tuner only sends along the requested programs.
(It may have changed, and TVH may now always use the full mux. But I seem to remember it as above when I was using TVH.)
True, and this is one of the advantages of TVH's way of doing things. It does not rely upon the device to tell you what channels it can tune. Instead, you tell it which channel you want, and it will try to tune it for you. This is great for those stations that may not always come in great and don't get picked up by the HDHR's background scans. (It was also nice with the Prime, because I could tell TVH to tune something even if the device itself said I was unsubscribed.)
I'm not 100% sure on how tvh communicates with HDHRs other than it tunes a frequency rather than a virtual channel (like Channels does).
I know you can do PID filtering in the hdhomerun_config cli, but I don't know if you can do something like addpids/delpids like you can with satip to reuse an existing session. I guess that's what tvh would be doing if it's not receiving the full mux and extracting streams itself.
Unfortunately, I don't think PID filtering is exposed at all in the http API unfortunately, so we wouldn't be able to craft an M3U with URLs that include frequencies and PIDs for the HDHR to send. The closest I think we could get is to specify the frequency and program ID (eg, http://[x.x.x.x]:5004/auto/ch586000000-17472), but a second request would go to the next available tuner even if on the same frequency instead of sharing the first tuner.
And from a Channels point of view, that's how it works with satip as well. It doesn't say 'hey, I already have a satip session open to transponder X, and the user just requested another channel on that same transponder, so let me just add those PIDs to the same session'. It would be great if it did, but I don't think the devs want to deal with that kind of complexity.
1 Like
Agreed. However, if Channels did (optionally/additionally) support using the more direct API, they could also open the door for using the EIT/program data embedded in the broadcasts. That would aid in channel/program scanning, and allow for more accurate recording. (While this isn't so important for US users, it would be a tremendous boon for EU/international users, where the program data is much richer.)
1 Like
ATSC3 is being deployed across the US right now, so this will become an important feature for US users before too long.
This information is actually stored in the tuner. Current ATSC1 models cannot specify/filter PIDs when accessed via HTTP.
However, the ATSC3 tuners do support specifying multiple PLPs in the URI when tuning over HTTP. However, I don't believe it supports modifying it on the fly the way can change the PID filter over their "legacy" UDP C API. For information, here's the forum post on accessing the ATSC3 http video stream.