Interpreting debugging values from the TCP interface

Want to write your own code to work with a HDHomeRun or work with the HDHomeRun DVR? We are happy to help with concepts, APIs, best practices.
mdlayher
Posts: 2
Joined: Tue Aug 15, 2017 4:52 pm

Interpreting debugging values from the TCP interface

Postby mdlayher » Wed Aug 16, 2017 8:48 am

Hi all,

I've got an HDHomeRun Prime here at home that I absolutely love, and since I'm a programmer, I've decided to poke around at the device's TCP interface with Go, to fetch and parse some of the information that can be retrieved by hdhomerun_config.

https://github.com/mdlayher/hdhomerun

The eventual goal is to build a Prometheus exporter, so I can monitor my HDHomeRun along with many of the other network-connected devices in my home.

I'm having no problem fetching values from the device, but I am finding it difficult to discern the meaning of some of them. Thus far, I've been using the HDHomeRun Development Guide, but it appears it was last updated in 2011.

https://www.silicondust.com/hdhomerun/h ... opment.pdf

Let's start off with the output of "/oob/debug".

Code: Select all

$ hdhomerun_config 13252C05 get /oob/debug tun: ch=oob2048:75250000 lock=oob2048:75250000 ss=98 snq=100 dbg=-448/-2228
This appears to be the same output that is used for the CableCARD menu on the Prime's web UI. However, I'm curious as to how the web UI can produce a signal strength measurement in dBmV, and a quality with a unit of dB.

Also, does anyone have any idea what the two numbers in the "dbg" field mean?

Next, I have some questions about the tuner debug output (when tuned to a channel).

Code: Select all

$ hdhomerun_config 13252C05 get /tuner0/debug tun: ch=qam:141000000 lock=qam256:141000000 ss=100 snq=100 seq=100 dbg=-392/-3639 dev: bps=38809216 resync=0 overflow=0 cc: bps=38810720 resync=0 overflow=0 ts: bps=3382496 te=0 crc=0 net: pps=336 err=0 stop=0
The "tun" line makes sense to me, other than the "dbg" member again.

According to the docs, "dev" is for "device status". What is the device? The tuner? The HDHR itself? And what do "resync" and "overflow" mean?

At first I thought that "cc" might be "CableCARD" but I'm not sure. It also appears that the values for "cc" are identical for all tuners on the device.

"ts" is for "transport stream", so is this the raw stream being delivered from my cable provider?

Lastly, "net" is for "network status", so the network stream being sent from my HDHR to the device consuming it? I'm unsure what the "stop" value means, but I've noticed it changes to "4" when I stop a stream to my phone.


Obviously there's a lot going on here, but if anyone has more insight into any one of my questions, I'd greatly appreciate it. I'd like to document each of these values in the Prometheus exporter I'm building, so that they could be useful for someone who would like to monitor their device as well.

Thanks for your time.

jasonl
Silicondust
Posts: 11987
Joined: Sun Oct 28, 2007 9:23 pm

Re: Interpreting debugging values from the TCP interface

Postby jasonl » Sun Aug 20, 2017 2:06 pm

For signal strength, a change of 3dBmV is 5%, with 100% being 0dBmV. There's a similar scale for dB on the snq, but it's different for each modulation and I don't have those committed to memory. The dbg numbers are different on each model, but are raw stats from the tuner about the signal strength and carrier offset - not particularly useful to anyone outside of us.

dev shows the status of the individual tuner. cc shows the status of the CableCARD (since all 3 tuners share the path into the CableCARD, it will be the same for all of them). ts is the filtered transport stream. net is the network stream for that tuner. resync is any time the transport stream doesn't have a sync byte where it should be at the start of a packet and it has to be found again. overflow means the buffer was exceeded.

stop is the reason why a stream was stopped. 0=not stopped, 1=stopped intentionally, 2=stopped by ICMP reject, 3=stopped due to network connection loss, 4=stopped by HTTP connection close.

mdlayher
Posts: 2
Joined: Tue Aug 15, 2017 4:52 pm

Re: Interpreting debugging values from the TCP interface

Postby mdlayher » Mon Aug 21, 2017 7:25 am

Excellent! Thank you so much. I'll comb through my code again and make sure I document things appropriately.

If I have any more questions, I'll be sure to ask here. Thanks for your time.


Return to “Development Support”

Who is online

Users browsing this forum: No registered users and 1 guest