Feature Requests for Future Firmware Updates

[Trip]

Nick, et al,

Got some thoughts for you. Most are specific to the ATSC 3.0 receivers, but the first one is not.

1) How feasible/challenging would it be to turn the HDHomeRun Config GUI into a web-based tool built into the tuner itself via a firmware update? I know that once tuned, it's possible to look at the parameters of the program currently tuned/streaming, but it's not possible to actually tune an RF channel, see/select the various subchannels on it, view the PLPs (if 3.0), etc., without having the HDHR tools installed on the computer. Considering that the Linux version of the HDHomeRun GUI is quite outdated at this point and still does not show the plpinfo data, I suspect it would be easier to use and keep updated, and it would be cross-platform.

2) Nick, I know at one point I'd asked directly about the in-built discovery scan functionality in hdhomerun_config returning the BSID as the TSID when looking at a 3.0 signal. When I dig into the SLT in the local signals, I see the BSID there on at least two of the three, but the scan functionality doesn't seem to be returning it in the spot where the TSID would appear in 1.0. I'm running the latest firmware, and the libhdhomerun GitHub code only has a single occurrence of the string "tsid" that I can find, and that's in a file that hasn't been updated since 2017, so I'm guessing it just still doesn't report the BSID at all.

3) Speaking of the SLT, could the HDHR perhaps add the ability to show the raw contents of some of the internal 3.0 XML files, like the gzipped SLT? In the absence of any actual analysis tools for 3.0, it's incredibly difficult to figure out what stations are doing on 3.0, and with pcap-formatted captures seemingly constrained to the development firmware, it means most people can't even dump a pcap file that I could painstakingly dig the stuff out of. In the alternative, some type of ability to just dump a short analysis of what's in the key elements of the signal would be even more useful, but I assume more work as well.

4) Not sure if you're working on the ability to view internet-delivered streams in 3.0 or not, but it would be nice if those could be exposed consistently. In the absence of actual support for them, it may be nice if they at least showed up in the discovery scan, perhaps with a "(streaming)" string akin to the "(encrypted)", "(control)", and "(no data)" strings that are attached in those cases. (That said, #3 above would make this a lot less necessary, though it would be nice if they could appear in the Live Bandscan.)

5) Similarly, it would be nice if the discovery scan would select all PLPs at scan time so it didn't just show "(no data)" for most 3.0 signals. Or, failing that, it at least flag encrypted streams, as it appears encryption status is listed in the SLT which I believe is in PLP0 most of the time anyway. (Same parenthetical as found in #4 applies to this item as well.)

Thanks for all you guys do!

- Trip

[Trip]

Nick,

One other issue I tripped over last month. It seems that in order to use the HTTP interface to grab PCAPs, you have to first scan using the web interface, even if you're trying to directly tune, for example, ch33p0p1. Is there any way to make it so that it can tune direct as long as a physical channel is being requested? I get needing the scan first for a virtual channel, but not for a physical one.

- Trip

[nickk]

5) Similarly, it would be nice if the discovery scan would select all PLPs at scan time so it didn't just show "(no data)" for most 3.0 signals. Or, failing that, it at least flag encrypted streams, as it appears encryption status is listed in the SLT which I believe is in PLP0 most of the time anyway. (Same parenthetical as found in #4 applies to this item as well.)

1) Channels scanning ATSC 3.0 is significantly more complicated and needs to be done by the device - the old hdhomerun_config scan feature will not work for ATSC 3.0 channels. You can use hdhomerun_config or http to trigger the device channel scan, then read back the lineup.json result via http.

2) It is not possible to "select all PLPs" and expect data. The idea will only work for broadcasts where there are 4 or fewer PLPs AND all PLPs are designed to be simultaneously tuned.

One other issue I tripped over last month. It seems that in order to use the HTTP interface to grab PCAPs, you have to first scan using the web interface, even if you're trying to directly tune, for example, ch33p0p1. Is there any way to make it so that it can tune direct as long as a physical channel is being requested? I get needing the scan first for a virtual channel, but not for a physical one.

Tuning by physical "ch" number does not require a scan first. Adding "p" after speeds up tuning as it tells the HDHomeRun that the channel is ATSC 3.0.

I will run a QA test of this later today.

[Trip]

Tuning by physical "ch" number does not require a scan first. Adding "p" after speeds up tuning as it tells the HDHomeRun that the channel is ATSC 3.0.

I will run a QA test of this later today.

Nick,

This is unfortunately not the case. I took my HDHR with me on the road and got a 503 error if I tried to directly use wget on the HTTP interface before doing a scan in the web interface. It took me until after I gave up and and thus did not collect two of the stations (WPNT and WWHO) before I figured it out. Having to do so added a lot of time to my stops to capture PCAPs of the 3.0 stations I encountered.

- Trip