Improvements to recording statistics

Understanding why a recording is pixelated or has strange artifacts is an ongoing issue that has caused a lot of frustration for users over the years. Figuring out why this is happening has always been difficult and has involved guessing and fiddling.

We've been logging [SNR] log messages for every HDHomerun-based recording for a while as we experimented with different ways to quantify if a recording had issues or not and how bad it was. We recently had a breakthrough that has allowed us to represent the numbers in a more meaningful way and has given us the confidence to display them in the UI.

In the latest DVR pre-release (press-and-hold on Check for Updates to upgrade to it) you will be able to see this additional information to help identify the source of recording issues.

Starting with v2020.02.28.0428 we will print additional fields in the [SNR] log message:

  • sigerr=10% indicates that 10% of the recording was impacted by signal issues (generally due to OTA antenna reception issues or cabling issues for Cable TV)
  • neterr=15% indicates that 15% of the recording as impacted by network issues (generally due to connection between the HDHomerun and DVR having issues, often times because of the use of WiFi or Powerline)
  • err=17% indicates that a total of 17% of the recording was impacted by the above two kinds of issues (it is possible to have reception and network issues happening at the same time or different times)

Here is an example log message with OTA reception issues for 5% of the recording:

2020/02/28 12:01:02.202551 [SNR] Statistics for "TV/The Young and the Restless/The Young and the Restless S47E122 2020-02-28-1129.mpg": ss=83%,81%-86% snq=51%,0%-59% seq=97%,0%-100% bps=19218627,0-19636224 pps=1263,0-1540 sigerr=5%

To make it easier to find these issues without having to dig through the DVR logs, we are also showing a warning when selecting View Details for a recording:

Please let us know how this works out for you!


Nice work, thanks!

This is awesome, I love this!

Nice addition.
Not sure where you're getting the bitrate though.
My example is closer to the full mux speed of the cable frequency and not the individual channel.

[TNR] Opened connection to 1323AADB/0 for ch758 HSTRYHP
[HLS] Starting transcoder for channel 758 from (encoder=remux, resolution=, deinterlacer=, bitrate=0)
[HLS] Probed live stream in 1.841352141s: h264 1280x720 progressive 2658094bps
[SNR] Statistics for ch758 HSTRYHP: ss=95% snq=100% seq=100% bps=38700462,18861664-38812224 pps=409,164-535

Should be 2-4 Mbps, not 18-38.

The bps and pps stats are coming directly from the tuner itself. It is quite likely it is the bitrate of the full mux. However, when the tuner selects a channel using its virtual channel number (like Channels does) the tuner hardware filters the requested PID. That probably accounts for the discrepancy.

You can monitor the values yourself by using SiliconDust's hdhomerun_config tool.

If you could download and run SiliconDust's hdhomerun_config tool when you've tuned to that channel and run:

hdhomerun_config <device> get /tuner<num>/debug

and give me the output it would be very helpful.

For what was in your logs:

[TNR] Opened connection to 1323AADB/0 for ch758 HSTRYHP

it would be

hdhomerun_config 1323AADB get /tuner0/debug

If it matters, running latest HDHR firmware release.
Model: HDHR3-CC
Firmware: 20200225

get /tuner0/debug
tun: ch=qam:279000000 lock=qam256:279000000 ss=95 snq=100 seq=100 dbg=-450/9119
dev: bps=38810720 resync=0 overflow=0
cc:  bps=77621440 resync=0 overflow=0
ts:  bps=3869792 te=0 crc=0
net: pps=373 err=0 stop=0

get /tuner0/status
ch=qam:279000000 lock=qam256 ss=95 snq=100 seq=100 bps=3772032 pps=361
1 Like

Thanks for this info. The latest pre-release will provide bps numbers that reflect the filtered channel rate.

1 Like

Okay, so when I look at the log for an error I'm having, this is telling me I have issues with my network then. correct?

2020/03/19 21:30:00.648105 [SNR] Statistics for "TV/Will & Grace/Will & Grace S03E15 Broadway Boundaries 2020-03-19-2100.mpg": ss=88%,0%-90% snq=91%,0%-97% seq=99%,0%-100% bps=7703780,2779392-14943744 pps=681,0-3369 neterr=11%

and the GUI display said this, so I need to move that box off of wifi it looks like and connect it via ethernet.

That's correct. The HDHR is unable to send data fast enough. It's often due to having the DVR connected via WiFi. Connecting via Ethernet will normally fix these sorts of issues.


IIRC, the SNR numbers in the log are in the format of Initial,Low-High, so in each element (Signal strength, Signal-to-Noise Quality, Signal Error Quality), it dropped down to 0 as reported by the tuner. While that may indicate network issues, it may also indicate a problem with the feed coming in to the tuner itself.

1 Like

@racameron: In the build adding these more statistics I changed the first number to be the median recorded instead of initial.

Ah, I thought I previously read it was the initial state. If it's actually now the median recording value, so much the better for assessing quality. Thank you.

@racameron: Your memory is correct. I changed it in build v2020.02.28.0428 because I suspected it would be more useful.

I am having a lot of problems with recordings. On one the odd things is it appears during recordings at night. I installed test flight and the beta test on one of my Apple TV’s, however the issue I’m having is with a AFTV.

Did you upgrade to the latest pre-release of the DVR software? That’s where this enhanced logging has been added. The log should help reveal issues.

The version I’m running is: 2020.03.14.1915
Thanks for your quick reply. I am not an idiot, neither am I a programmer. I’m a bit confused. I am running the DVR software on a Windows 10 laptop, storage is a Mycloud 4 TB NAS, 2 4K FireTVs, and a 4K AppleTV. I normally only use the FireTVs, but I installed TestFlight on my IPad and AppleTV just to participate in the beta trials.

Should I install the prerelease DVR software on my laptop? How?

I am currently upgrading my DVR to version: 2020.03.24.0127

This is another thing that I’m curious about. There are many messages about the buffer.