linux hdhomerun_config_gui and GTK2

[gtb]

Just a heads up that some future linux distros are intending to not include the GTK2 development libraries (whether a 3rd party will build them and make them available before those future distros are released to the public is unknown at this time). That will mean the hdhomerun_config_gui application will no longer be able to be built on those distros.

It may be time to either update to GTK3 (first available around 10 years ago), port to a different GUI toolkit, or consider a new approach entirely, for the functionality.

[nickk]

We have discontinued support for the GTK version of HDHomeRun Config GUI.

There are some options for a replacement, although the majority of customers use the Windows version.

[gtb]

We have discontinued support for the GTK version of HDHomeRun Config GUI.

Thanks. I guess I must have completely missed the EOL announcement. My bad.

I believe I saw it on a download page ( here: https://info.hdhomerun.com/info/linux and a reference here: viewtopic.php?p=38124&hilit=hdhomerun_config_gui#p38124 ). Perhaps the references should be removed, or at least come with a warning about it being legacy.

There are some options for a replacement, although the majority of customers use the Windows version.

Personally I don't use it, so I mostly don't care, but one of my primary distros packages defaults to trying to build it. I'll try to remember to open some tickets to let the packager know they should probably stop building it going forward.

Thanks.

[Trip]

There are some options for a replacement, although the majority of customers use the Windows version.

Are these options noted somewhere? I've not found any replacement GUI options. I do wish there were a Linux GUI option that looked like the current Windows version and supported the PLP info.

- Trip

[dwstudeman]

There are some options for a replacement, although the majority of customers use the Windows version.

Are these options noted somewhere? I've not found any replacement GUI options. I do wish there were a Linux GUI option that looked like the current Windows version and supported the PLP info.

- Trip

I switched from Kubuntu back to Debian for KDE stability, and I no longer have the config GUI available.

[Trip]

I've been experimenting with Google Gemini over the past few weeks and in the past two days decided to try to tackle this issue. Using Gemini, I've produced a curses-style tool that imitates the functionality of the GUI, but adds the 3.0-specific functions.

https://www.rabbitears.info/dl/hdhomeru ... ui_0.2.zip

Included is the Makefile and the source file, plus my executable for Ubuntu 24.04. I'm not a programmer, so I know this isn't typically how things get distributed, but it's what I can do.

I hope to do more with it, but I'd be interested to hear feedback on it.

EDIT: Already moved from 0.1 to 0.2 which works much better. Still more I want to do.

- Trip

[Trip]

Here's version 0.3:

https://www.rabbitears.info/dl/hdhomeru ... ui_0.3.zip

I ran myself out of Gemini credit until later tonight, but it's in really good shape. It does almost everything the GUI version does, including seeking for channels and showing the network rate and target. (It does not currently view streams, as I am having a hard time picturing a command line application launching VLC, but maybe I'll try that too.) It also does some things that the GUI version does not do, like show the TSID and record a transport stream (in 1.0).







There's a UI bug in the transport stream recording code I'm trying to hammer out. After that, I'm going to see if I can't persuade it to do something to capture packets and/or debug data in 3.0.

- Trip

[nickk]

Playing with hdhomerun_tui now - awesome!!

[nickk]

Minor request - can you please limit the poll rate to half a second (2 per second) to be sure older devices can handle the requests.

I could even select PLPs - impressed!

Nick

[Trip]

Minor request - can you please limit the poll rate to half a second (2 per second) to be sure older devices can handle the requests.

I could even select PLPs - impressed!

Nick

Glad you are liking it! I hope others are able to find it useful as well.

Here's the newest build: https://www.rabbitears.info/dl/hdhomeru ... ui_0.4.zip

I think I got all the UI stuff fixed, and now it supports recording 1.0 transport streams, 3.0 debug output, and 3.0 PCAP on dev receivers. (It checks for dev status based on the presence of the dB numbers.) For 3.0 support to work, the system needs to have wget installed, as I don't think the "save" function supports 3.0 at all, but please correct me if I'm wrong as I'd prefer not to have the external dependency. I won't promise it's perfect as it needs more testing, but I think I have most of it working as it should be at this point.

Let me turn your request back on you--which older devices have the issue with the poll rate? I like having the most instantaneous data I can, particularly when I'm on the side of the road with my antenna trying to look at local signals. I'd rather restrict any such limit to the devices that need it. My HDHR3 seems okay with it as-is. Also, is the limit per request type (target, status, streaminfo, etc) or across all requests combined?

Other than potentially seeing if it can feed the video to VLC for viewing like the GUI does, have I overlooked any features that it should have? Not just a question for Nick; if there's anyone else looking at this with thoughts, feel free to add you opinions.

Finally, while I know this is the wrong place for it, if I may make a feature request for future HDHR-4K firmware, it would be really amazing if there were a way to get the SLT and perhaps the other stream parameters and/or raw XML files (video parameters, audio parameters, etc) directly from the HDHR. It would significantly ease updates to RabbitEars. I could add that information into this tool as well. I've been separately trying to write a tool to parse the PCAP and/or debug output directly with limited success; I can get the SLT but the other stuff has been evasive. EDIT: Also, is it possible to get more detail out, like whether it's a short or long LDPC, in plpinfo? I'd love to be able to determine the theoretical minimum SNR needed for a given PLP.

- Trip

[nickk]

Fast update - thanks!

I don't think the "save" function supports 3.0 at all, but please correct me if I'm wrong as I'd prefer not to have the external dependency.

The old UDP streaming approach used by save should work for ATSC 3.0 in the converted TS format. You can tune by vhannel or by frequency+program but either way the virtual channel must be known to the HDHomeRun from the last on-device channel scan.

Or you can stay with the newer HTTP approach by coding up a quick TCP connection. The HTTP request is a short text string you send via the socket (single call to send). What you get back from the HDHomeRun - ignore everything until you see \r\n\r\n and from there you have pure TS data.

Let me turn your request back on you--which older devices have the issue with the poll rate? I like having the most instantaneous data I can, particularly when I'm on the side of the road with my antenna trying to look at local signals. I'd rather restrict any such limit to the devices that need it. My HDHR3 seems okay with it as-is. Also, is the limit per request type (target, status, streaminfo, etc) or across all requests combined?

The gen 1/2/3 ATSC devices have only 64k of data RAM and 256k of instruction RAM (plus they can execute at 1/250th the speed directly from flash, not cached). Each request is a new TCP connection and we have to keep TCP connections around in RAM after the remote closes the connection. Also depending on the operation there is I2C overhead that takes away from delivering the stream data.

My recommendation is to limit the total number of requests to less than 10 per second. For example if you are pulling 3 things then 3 updates a second. I guess you could be cleaver and pull the signal info more often and the program info less often. We didn't worry about it because updating twice a second seemed fast enough.

I also seem to remember one demod used in one of the older models only reports new signal quality information once a second. You can pull it faster but you get the same value.

Finally, while I know this is the wrong place for it, if I may make a feature request for future HDHR-4K firmware, it would be really amazing if there were a way to get the SLT and perhaps the other stream parameters and/or raw XML files (video parameters, audio parameters, etc) directly from the HDHR. It would significantly ease updates to RabbitEars. I could add that information into this tool as well. I've been separately trying to write a tool to parse the PCAP and/or debug output directly with limited success; I can get the SLT but the other stuff has been evasive.

Yeah, seems like a good idea... let me get back to you on that.

Nick

[Trip]

The old UDP streaming approach used by save should work for ATSC 3.0 in the converted TS format. You can tune by vhannel or by frequency+program but either way the virtual channel must be known to the HDHomeRun from the last on-device channel scan.

Or you can stay with the newer HTTP approach by coding up a quick TCP connection. The HTTP request is a short text string you send via the socket (single call to send). What you get back from the HDHomeRun - ignore everything until you see \r\n\r\n and from there you have pure TS data.

My goal is to grab the entire signal to evaluate, so the UDP streaming approach doesn't sound like a solution here for 3.0. I'll have to look into the TCP connection idea; it'd be nice to avoid having to go to wget to save the data.

The gen 1/2/3 ATSC devices have only 64k of data RAM and 256k of instruction RAM (plus they can execute at 1/250th the speed directly from flash, not cached). Each request is a new TCP connection and we have to keep TCP connections around in RAM after the remote closes the connection. Also depending on the operation there is I2C overhead that takes away from delivering the stream data.

My recommendation is to limit the total number of requests to less than 10 per second. For example if you are pulling 3 things then 3 updates a second. I guess you could be cleaver and pull the signal info more often and the program info less often. We didn't worry about it because updating twice a second seemed fast enough.

The next update will look at the device ID and do refreshes at 500ms intervals for IDs lower than 10400000 and leave it at 100ms for others, at least for the time being. The 4K, at least, definitely seems to be able to update that fast. I've already implemented this and am going to work on a few more things before calling it 0.5 and uploading it.

And the updates are quite fast because I have Google Gemini doing most of the work. This is basically an experiment for me to see how much I can do with it, assuming I give it good instructions and carefully validate what it gives me. The answer, so far, is that I can do quite a bit and quite quickly. I'm not terribly good at C, but am managing just fine with this project!

Yeah, seems like a good idea... let me get back to you on that.

I'd love to be able to pull an HTML file of some sort right out that is in the spirit of the TSReader HTML export. I could tell people to just go to a specific address on their HDHR to see the file, then save it and send it to me. Would really help me with trying to keep 3.0 up to date; right now, it's really sparse because it's just so hard to get solid info out.

Separately, not sure if you saw my later edit to the last message, but is it possible to get more detail out, like whether it's a short or long LDPC, in plpinfo? I'd love to be able to determine the theoretical minimum SNR needed for a given PLP and perhaps stick that in this utility as well. I can give a decent range without it, but could narrow it more with it.

- Trip

[nickk]

Checking for lower than 10400000 isn't quite right as modern TECH devices are lower than 10400000 and legacy EU devices are higher.

libhdhomerun has a function for this - hdhomerun_discover2_device_is_legacy()

If you take a look at the implementation of hdhomerun_discover2_device_is_legacy() in hdhomerun_discover.c you will see the logic. Best is to use this API rather than replicating it though.

Nick

[Trip]

Checking for lower than 10400000 isn't quite right as modern TECH devices are lower than 10400000 and legacy EU devices are higher.

libhdhomerun has a function for this - hdhomerun_discover2_device_is_legacy()

If you take a look at the implementation of hdhomerun_discover2_device_is_legacy() in hdhomerun_discover.c you will see the logic. Best is to use this API rather than replicating it though.

Nick

Done. Here's 0.5.

https://www.rabbitears.info/dl/hdhomeru ... ui_0.5.zip

Other changes:

It now supports viewing channels with VLC (in 1.0, doesn't work in 3.0 yet)
It has a "PLP Details" screen which uses the tables in A/327 to provide a range of potential minimum SNRs for each PLP
No longer requires wget
When the number of subchannels is greater than 7, it now splits across two columns
To stop it from inadvertently changing tuners due to the scroll wheel, I disabled mouse controls (I'm sure there has to be a way to keep the mouse available for copy and paste without permitting the scroll wheel, but no luck yet)

I might be forgetting some things.

- Trip

[sdust]

Thanks for writing the app. Super useful.

It would be nice if we could get some history in addition to the instantaneous values in order to better catch momentary drop outs.

Maybe a histogram or a lighter color for the current bar above the minimum in the last few seconds.

[████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒^·················]
|<------- bright -------->|<--------- dimmed ---------->| empty
(min=40%) (up to current=80%)