get a better NIC. like a usb gigabit adapter.
otherwise, recommend using something newer/better as your server.
The laptop is one year old. The NIC is outdated to be sure. I was using a 4T MyCloud previously and I didn’t have nearly as many problems.
I have ordered a USB NIC, I’m hoping it will help.
USB 3.0 gigabit NIC would be best. if the laptop has usb 3.0
1 Like
I couldn’t stand it any more. I got a USB 3.0 to gigabit adapter from Best Buy, curbside. It looks like it has solved all of my problems.
Dell sucks, I never thought about the laptop having a 10/100 NIC until now. I thought I just needed to update the drivers.
2 Likes
My few year old Dell Precision 5510 does not have a wired NIC at all. it too thin a machine
I just use a USB C Gigabit NIC when i want wired connection.
Which of the following debug values from my example post go into determining sigerr?
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
Noticed these in my DVR log on different channels from my Prime tuner.
ss=95% snq=100% seq=100% bps=3922097,2884672-5333184 pps=376,284-507 sigerr=5%
ss=97%-98% snq=99%,98%-100% seq=100% bps=3409680,2078528-5378304 pps=336,210-523 sigerr=1%
ss=95%-96% snq=100% seq=100% bps=1585849,792608-2280064 pps=168,97-233 sigerr=5%
ss=96% snq=100% seq=100% bps=2035246,1815328-2341728 pps=208,190-238 sigerr=5%
ss=96%-97% snq=100% seq=100% bps=1767367,395552-2528224 pps=185,67-256 sigerr=5%
Figures it's nothing to worry about assuming the percentage is percentage of times you polled (once/second?) the debug info.
Results I showed from the log were from streaming different Prime tuner channels live, first one for 35 seconds, next one 3 minutes and 8 seconds, next one 37 seconds, next one 36 seconds and final one 36 seconds.
Do you happen to know what the ts:te transport error indicates?
Is it number of TEI bits set in the transport stream?
Yes it counts the number of packets with the TEI bit set.
So obvoius next question is if HDHR tuner demodulator sets the TEI bit in a TS packet it means it's corrupt, so does the HDHR tuner just drop that TS packet?
Reason I ask is running recordings through TSReader, there are no TEI erros.
I'm not sure if the packet is dropped. I don't think it is, usually you can see it in the stream.
Couldn't find an issue.
Recorded one of those channels for 39 seconds and it shows sigerr=5%
2020/07/10 16:46:26.945101 [DVR] Starting job 1594423800-ch768 Family Guy on ch=[768]
2020/07/10 16:46:27.404963 [TNR] Opened connection to 1323AADB/0 for ch768 FRFMHDP
2020/07/10 16:46:27.405322 [DVR] Recording for job 1594423800-ch768 from 1323AADB ch768 into "TV/Family Guy/Family Guy S17E19 2019-05-05 Girl Internetted 2020-07-10-1646.mpg" for 13m33.054768399s
2020/07/10 16:46:27.434242 [DVR] Refreshing metadata for Family Guy (184483)
2020/07/10 16:46:28.194472 [IDX] Generating video index for job 1594423800-ch768
2020/07/10 16:47:06.722998 [SNR] Statistics for "TV/Family Guy/Family Guy S17E19 2019-05-05 Girl Internetted 2020-07-10-1646.mpg": ss=93%-94% snq=100% seq=100% bps=3542371,1937152-5196320 pps=341,195-494 sigerr=5%
2020/07/10 16:47:06.723688 [TNR] Closed connection to 1323AADB/0 for ch768 FRFMHDP
2020/07/10 16:47:06.723739 [DVR] Job cancelled: 1594423800-ch768 Family Guy
So I figured it's an issue on that cable frequency.
I captured the full cable mux of that frequency for 4 minutes, 31 seconds and see no issues.
hdhomerun_config FFFFFFFF set /tuner2/channel auto:267000000
Tuner 2 Status
Virtual Channel none
Frequency 267.000 MHz
Program Number none
Authorization none
CCI Protection none
Modulation Lock qam256
PCR Lock locked
Signal Strength 94% (-3.8 dBmV)
Signal Quality 100% (36.8 dB)
Symbol Quality 100%
Streaming Rate 38.806 Mbps
Resource Lock none
hdhomerun_config FFFFFFFF get /tuner2/debug
tun: ch=auto:267000000 lock=qam256:267000000 ss=94 snq=100 seq=100 dbg=-456/8680
dev: bps=38810720 resync=0 overflow=0
cc: bps=38810720 resync=0 overflow=0
ts: bps=38810720 te=0 crc=0
net: pps=3686 err=0 stop=0
hdhomerun_config FFFFFFFF save /tuner2 prime.ts
................................................................................
................................................................................
................................................................................
................................
-- Video statistics --
1004855 packets received, 0 overflow errors, 0 network errors, 0 transport errors, 0 sequence errors
hdhomerun_config FFFFFFFF set /tuner2/channel none
Looking at the captured mux, TSReader shows no TEI errors.
How does Channels DVR figure I had sigerr=5%
P.S. I know my HDHR Prime and cable service don't have issues. Also doubt anyone makes short recordings or looks at logs. Just wondering where the 5% comes from.
Figure it must be from initial tuner lock to channel.
Per Silicon Dust re: tuner debug info
https://info.hdhomerun.com/info/hdhomerun_config#checking_the_signal_strength
"The counters are reset to zero upon a channel change, but may indicate a small number of errors caused before the tuner locks on the channel. As a result, diagnostics should be based on the change in values over time, and not the initial values."
Would it be possible to also show these stats when playing a live channel in the web browser. Right now we can see the trans-coding and the frames per sec.
I started a recording from the web UI guide, then cancelled it after 13 seconds which gave sigerr=14%
2020/07/11 14:10:00.156120 [DVR] Starting job 1594498800-ch768 The Hunger Games (2012) on ch=[768]
2020/07/11 14:10:00.604485 [TNR] Opened connection to 1323AADB/0 for ch768 FRFMHDP
2020/07/11 14:10:00.604937 [DVR] Recording for job 1594498800-ch768 from 1323AADB ch768 into "Movies/The Hunger Games (2012) 2020-07-11-1410.mpg" for 2h24m59.843726297s
2020/07/11 14:10:00.661024 [IDX] Generating video index for job 1594498800-ch768
2020/07/11 14:10:13.688196 [SNR] Statistics for "Movies/The Hunger Games (2012) 2020-07-11-1410.mpg": ss=94% snq=100% seq=100% bps=3315890,2995968-5378304 pps=318,291-511 sigerr=14%
2020/07/11 14:10:13.688793 [TNR] Closed connection to 1323AADB/0 for ch768 FRFMHDP
2020/07/11 14:10:13.688877 [DVR] Job cancelled: 1594498800-ch768 The Hunger Games (2012)
I then started watching the same channel in the web browser, then selected to record it again for 13 seconds from another tab in the browser and no sigerr on this recording.
2020/07/11 14:15:02.850122 [TNR] Opened connection to 1323AADB/0 for ch768 FRFMHDP
2020/07/11 14:15:02.850975 [HLS] Starting transcoder for channel 768 from 192.168.1.2 (encoder=remux, resolution=, deinterlacer=, bitrate=0)
2020/07/11 14:15:04.688057 [HLS] Probed live stream in 1.836855233s: h264 1280x720 progressive 2336330bps
2020/07/11 14:15:06.364755 [HLS] Session ch768-dANY-ip192.168.1.2 started in 4.062013577s
2020/07/11 14:15:06.366021 [ENC] Starting encoder for ch768 in /volume1/arkives/ChannelsDVR/Streaming/ch768-dANY-ip192.168.1.2-609139177/encoder-1-127564852 at 1 (2.200378) (encoder=remux, resolution=720, deinterlacer=hardware, bitrate=2336 segment_size=0.01)
2020/07/11 14:15:06.402860 [HLS] ffmpeg: ch768-dANY-ip192.168.1.2-1-copy-aac--2336-128-720-0-0--hardware-false-false-0.01: [h264 @ 0x3b5ae80] mmco: unref short failure
2020/07/11 14:15:06.408334 [HLS] ffmpeg: ch768-dANY-ip192.168.1.2-1-copy-aac--2336-128-720-0-0--hardware-false-false-0.01: [h264 @ 0x3b5ae80] Increasing reorder buffer to 2
2020/07/11 14:15:06.413022 [HLS] ffmpeg: ch768-dANY-ip192.168.1.2-1-copy-aac--2336-128-720-0-0--hardware-false-false-0.01: [h264 @ 0x3b5ae80] Increasing reorder buffer to 3
2020/07/11 14:15:24.087853 [DVR] Starting job 1594498800-ch768 The Hunger Games (2012) on ch=[768]
2020/07/11 14:15:24.088059 [TNR] Sharing existing connection to 1323AADB/0 for ch768 FRFMHDP (clients=2, len=0)
2020/07/11 14:15:24.088308 [DVR] Recording for job 1594498800-ch768 from 1323AADB ch768 into "Movies/The Hunger Games (2012) 2020-07-11-1415.mpg" for 2h19m35.912049404s
2020/07/11 14:15:24.114150 [IDX] Generating video index for job 1594498800-ch768
2020/07/11 14:15:37.142577 [SNR] Statistics for "Movies/The Hunger Games (2012) 2020-07-11-1415.mpg": ss=94% snq=100% seq=100% bps=3966578,2168768-4746624 pps=376,146-454
2020/07/11 14:15:37.143088 [DVR] Job cancelled: 1594498800-ch768 The Hunger Games (2012)
1 Like
Aren't the stats displayed in the Activity section? You can open a second browser window to display that page to see the stats.
(Yes, it's annoying as it involves multiple windows, and could be added to the caption that displays the transcoding status. But, the info is available.)
I'm pretty sure (can't remember where I saw it) that Channels DVR polls an HDHR once per second for the debug info to gather stats on the tuner session. That would be a lot of info to display in addition to what they already do and may confuse some people. Think it's for logging only and not for general stat info.
We mark a given poll interval as bad if the transport error counter incremented since last time OR if the seq value was less than 100%.
Our final percentages are the number of polling intervals that were good vs not good.
Trying to understand.
How often are your poll intervals?
According to the logs the SEQ never went below 100%, so I'm assuming it's the TE counter, unless the logs don't show a dip in SEQ you saw while polling.
It appears from my experiment you quoted you're polling too soon while the tuner is just locking the channel and a few te errors could be expected.
14% of 13 seconds is 1.82 seconds, so if you're polling every second it doesn't make sense that 1.82 poll intervals were bad.
It polls every 2 seconds, starting 1 second after the DVR has connected to the HDHR.
I have found an issue with how I was calculating the minimum value if the initial values we fetched were 0. In the latest DVR pre-release I've improved the calculation to properly reflect the minimum value received. Let me know if the logs make more sense now.
1 Like