You said: If not then I can see why sometimes you are using multiple devices for same channel.
Well no because I do have tuner sharing enabled on all my devices (local and remote) and do have the tuner order the same on all my devices (local and remote), but still using up 2 tuners on my HDHR's for the same channel at random times.
If this Global setting does control remote devices, hopefully it will tackle the random 2 tuner for the same channel problem that I am having!
PS: It could be an ATSC3 tuner sharing problem specifically, since that is typically all that I use since ATSC3 went live in my market a few months ago.
ASTC3 Is so different because only the first 2 tuners are capable of receiving them... I have all my ATSC3 disabled .... so I am bowing out of this thread for now.
Thanks for the diagnostics. Looking through them, I see a couple things that jump out:
The clock on that device is way off. It was reporting it was 8/14/2022 right before the diagnostics were submitted
The server reported an error when it tried to tune to the first device and caused the client to retry to the next one (which is the correct behavior when the client encounters an error trying to tune to a channel)
I can't easily correlate the timestamps between the failures, but I do see some issues in the logs that line up with the HDHR device identifier and the channel that was being tuned to that indicate reception issues:
2022/08/18 08:15:53.059692 [SNR] Statistics for ch107.1 KETV: ss=84%,15%-86% snq=99%,0%-100% seq=99%,0%-100% bps=0 pps=445,0-742
...
2022/08/18 08:16:30.594412 [ERR] Failed to start stream for ch107.1: HDHomeRun: 807 No Video Data
So it appears that the original HDHR was having reception issues at the time the client tried to tune in, so it rolled over to the next HDHR and channel that was available.
The Clock- would that have any effect on Tuner Sharing behavior? Would it be incorrect since I just enabled "help improve channels" on that device? It's set to automatic like all other devices. I could look into that further if you would like.
The logs that you posted were dated 2022/8/18 which is after the date you mentioned of 8/14/22. If the internet was down at the time of the 2022/8/18 logs error, would that trigger said errors? Asking because there was an outage a few days back and I know we tried to tune into Channels DVR during that time. Rebooted the modem and everything was back up.
My ATSC3 signal here is strong, solid, and reliable. It sits at 87% Signal, 100% Quality, and 100% Symbol Quality at all times. Signal varies by maybe 1 or 2% and that's it.
Also, I have mentioned in a previous thread that sometimes when I tune to an ATSC3 channel (107.1), it will take an extra long time, then start playing the 7.1 channel instead even though Tuner Sharing is enabled AND there are other ATSC3 slots available to Channels DVR. Do you think that issue is related to this Tuner Sharing issue? Same goes with all other ATSC3 channels too not just 107.1. It will randomly play 6.1 instead of 106.1, 3.1 instead of 103.1, etc.
No, it just makes it harder to match up the logs with the server to diagnose the issue.
No, that wouldn't have any impact.
If you can see what's going on, it will help us correlate as we diagnose things.
The 8/14/2022 date was what I believe is the incorrect date that the client was reporting right before it submitted the diagnostics.
No, the internet being down should have no impact on recording or watching Live TV or recorded content.
The [SNR] logs that you see at the end of a session are what Channels is seeing from the HDHR statistics. We poll the HDHR every 2 seconds and report the last value and the range of values we had seen. Seeing seq=99%,0%-100% means that the Symbol Quality was 99% on the latest check we did, but had varied from 0% to 100% during the course of the broadcast. pps=445,0-742 means we most recently saw 445 packets per second, but that it was as low as 0 packets per second for at least one 2 second interval during the playback.
The error HDHomeRun: 807 No Video Data means that the HDHR tried to tune to a channel and was unable to get any video data from the signal.
These things all lead me to believe that you do have issues with reception from time-to-time (or, less likely, you are running into an HDHR hardware failure).
This again sounds like the behavior that we would expect when there are reception issues with a channel and Channels rolls over to the next priority channel that is similar.
If we can get another diagnostic log from the client right after something like this happens, it will help us track down if there is something more unusual going on here.
I will take a look at the clock/date situation asap!
From what you are saying, I interpret this as being either: an issue with the ATSC3 signal coming in (ATSC3 is a new deal here in my market so maybe something is screwed up? -OR- a HDHR hardware failure because the HDHR is always showing a strong signal in the web interface.
I will run this by the Silicondust guys and see what they think! Thanks very much for looking into this.
PS: Thinking about this further, the 1st priority tuner is the HDHR that I got from the Kickstarter project they had. Maybe it's not up to snuff as the "release" version in some way or faulty and spitting out some faulty data? The firmware is the latest on both HDHR's. If I did swap out the tuner with a different one, would I be able to set all my devices to tune them in the same order remotely, like the Global setting above??
If you're not monitoring the signal strength every second that you're watching TV, you wouldn't necessarily notice a drop in signal strength if you had some environmental issues causing reception problems. It could be a hardware problem but it also could just be a boring reception issue.
I have monitored the signal a lot, F5 to refresh, F5, F5, F5 and it's always appeared solid. No cut outs or anything during regular playback. I'm not saying it's not possible but it's very unlikely.
Is Silicon Dust not responding to you?
All the lines that end with - no video data, like this one below means the tuner isn't getting the channel tuned
20220822-17:00:50 HTTP: rejecting request from 192.168.1.180 - no video data
Which is a result of this tuning request a line above
Instead of constantly watching the logs, why not use the hdhomerun_config_gui tool, which will show live stats and a progress bar of sorts. Or better yet, while watching in Channels you use the "Show Stats" option from the Info tab of the Quick Guide to overlay the tuner stats while live viewing in Channels.
racameron is right. Could just be a momentary signal loss due to interference.
Very hard to pinpoint unless you have a good spectrum analyzer, and then it could be the tuner itself, or its power supply, or nearby electronics, even fluorescent lighting interfering.
They make great hardware, but seem to be lacking on selling and supporting it lately.
I have their Prime tuner and love it. Their support, not so much.
That's a lot of log data. If you search for no video data and correlate the timestamps (in UTC time) with your local time, do you see any particular time of day they happen at? There was a post in the SD forum of a guy who found LED lights on a dusk-dawn timer/sensor causing issues at night.
Here they are from your #1
20220819-02:33:40 HTTP: rejecting request from 192.168.1.180 - no video data
20220819-21:45:50 HTTP: rejecting request from 192.168.1.180 - no video data
20220822-01:05:03 HTTP: rejecting request from 192.168.1.180 - no video data
20220822-02:54:13 HTTP: rejecting request from 192.168.1.180 - no video data
20220823-01:48:17 HTTP: rejecting request from 192.168.1.180 - no video data
#2
20220819-02:33:49 HTTP: rejecting request from 192.168.1.180 - no video data
20220819-21:14:19 HTTP: rejecting request from 192.168.1.180 - no video data
20220819-21:45:58 HTTP: rejecting request from 192.168.1.180 - no video data
20220819-23:05:38 HTTP: rejecting request from 192.168.1.52 - no video data
20220822-01:05:11 HTTP: rejecting request from 192.168.1.180 - no video data
20220822-17:00:39 HTTP: rejecting request from 192.168.1.180 - no video data
20220822-17:00:50 HTTP: rejecting request from 192.168.1.180 - no video data
Thanks to my notepad++
If you noticed, there are times when both tuners failed to lock on a channel.
