Mine are now disabled too.
I will say it's getting increasingly frustrating how the devs pick and choose what they want to respond to around here.
It irks me though. I spent the extra $ on the ATSC 3.0 tuner.... i intend to make use of its capabilities.
The negatives of NextGen 3.0 though, make things more annoying. DRM on the stations I watch, and audio volume super low and AC4, and picture quality not any better than 1.0. (these are not the fault of Channels DVR though)
This issue of super slow tunning is a issue with Channels DVR, as all other apps i try, tune very fast.
It is not a crippling issue, but sure is an annoying one.
1 Like
Now imagine our frustration some of us have with the HomePod lag and audio issues that has been reported for and been waiting for years. It works perfectly in other apps except this one.
1 Like
Homepod issues are mainly related to AirPlay2. Many people have issues outside of Channels. Found this article that mentions issues
I recently tried Stereo Pair with a set of Minis, and took multiple tries, resetting, ungrouping, re-grouping. Finally got them working.
Worked fine in Channels for me for a couple days i used them. Only notice slight delay for them to start playing sound, does that in everything. No issues of lag or audio delay/sync for me.
Stopped using them as they sound like crap compared to my dedicated DAC and 2.1 speaker setup.
Ya tell me about it. I bought 2 of the 3.0 tuners to replace my 1.0's. 
I thought i read somewhere that the tuners in the 4K Flex model are more sensitive than the older 4 ATSC1.0 tuner Quadro tuner. That older tuner I also have had die/ have issues on me 2x, and had to deal with SD RMA, which took forever.
In Los Angeles I currently have 5 major channels in ATSC 3.0. Two of them (CBS and NBC) have DRM, so I can't access them. The other three (KTLA, KTTV, and KCOP) all come in fine, and everytime I've tested them lately, they come in quickly, too. The audio is fine. I don't know what I'm doing differently or why lots of you are experiencing slow tuning... just offering this as a data point.
1 Like
Yea. They seem to always have DRM no matter the market.
1 Like
Only the 2 Fox channels are DRM
I think it has to do with the individual market and how they implemented 3.0. In my market the 3 hevc channels tune in under 4 seconds. I also have no audio issues whatsoever. Volume is perfect and my receiver decodes ac4 without issue.
2 Likes
I hate to say it but you probably should disable your 3.0 channels for a year and circle back.
So - was thinking about this. Given that the client/DVR/DRM/etc are all pretty much constants in people who are seeing good or bad results (and completely dismissing network, given fast performance for you elsewhere)...
That leaves one variable - the RF/channel itself, in play. I'm wondering if there is something in the modulation or error correction (which absolutely varies on a per-channel basis), or perhaps the PSIP info, which might be causing the issue.
What does the info on the channel from the HDHR Config GUI look like?
Whatever it is, as i mention already, it tunes super fast in the HDHR app, it only Channels that it turtle slow.
Both stations takes the same time to tune, 15 to 20 secs.
3 Likes
Yep. I get it - I'm listening to you on the "it works elsewhere" front, read my response again. Just trying to see if other variables are causing the channels only issue.
I'll compare these to my "working" ATSC3 channels, and see if i spot any differences there. I'm wondering if QAM256 or PLP is in play.
One other thing to maybe try - does transcoding the channel help here, probably by forcing HLS? It probably won't, but it may give some information in the DVR logs that would otherwise not be there...
1 Like
Fixed image post. Also notice that the check box for PLPs does not always auto check, when tuneing. Most of the time it does, but some times it does not. Does not seem to affect tune time.
2 Likes
Yea i did try transcoding, and it only then takes longer to tune, adding maybe 3-5 secs. Same if i enable tuner sharing.
Not shocking. I'm just wondering if the transcoding opening (especially comparing to an ATSC1 channel) might show something in the logs that could point us somewhere...
When i said, i had tried transcoding, that was when i first posted, so Aug 18...
I just tried it again, enabling the setting in the app to Always use HLS for HDHR, and there is a change.
It takes about 5 secs to tune.
Activity on server reports its is Remuxing though.
But logs here.
2023/09/21 07:06:01.286981 [TNR] Opened connection to 10A03099/0 for ch105.1 KSTP
2023/09/21 07:06:01.320264 [HLS] Starting live stream for channel 105.1 from 192.168.0.17
2023/09/21 07:06:02.690594 [HLS] Probed live stream in 1.3703295s: hevc 1920x1080 progressive 22249298bps
2023/09/21 07:06:05.872471 [HLS] ffmpeg: ch105.1-dANY-ip192.168.0.17-remux: [hls @ 0000000003ce5e00] Stream HEVC is not hvc1, you should use tag:v hvc1 to set it.
2023/09/21 07:06:05.872471 [HLS] ffmpeg: ch105.1-dANY-ip192.168.0.17-remux: [mpegts @ 0000000002737140] Stream 1, codec ac4, is muxed as a private data stream and may not be recognized upon reading.
2023/09/21 07:06:05.872471 [HLS] ffmpeg: ch105.1-dANY-ip192.168.0.17-remux: [mpegts @ 0000000002737140] Stream 2, codec ac4, is muxed as a private data stream and may not be recognized upon reading.
2023/09/21 07:06:25.774506 [HLS] Stopping transcoder session ch105.1-dANY-ip192.168.0.17 (out=24.290933s finished=false first_seq=1 last_seq=23)
2023/09/21 07:06:25.787274 [TNR] Closed connection to 10A03099/0 for ch105.1 KSTP
2023/09/21 07:06:25.799518 [SNR] Statistics for ch105.1 KSTP: ss=96%,95%-97% snq=100% seq=100% pps=407,281-482
2023/09/21 07:06:25.799518 [SNR] Buffer statistics for ch105.1 KSTP: buf=0% drop=0%
2023/09/21 07:06:32.451702 [TNR] Opened connection to 10A03099/0 for ch123.1 WUCW
2023/09/21 07:06:32.458482 [HLS] Starting live stream for channel 123.1 from 192.168.0.17
2023/09/21 07:06:33.787108 [HLS] Probed live stream in 1.3286263s: hevc 1920x1080 progressive 24239177bps
2023/09/21 07:06:37.411455 [HLS] ffmpeg: ch123.1-dANY-ip192.168.0.17-remux: [hls @ 0000000002857940] Stream HEVC is not hvc1, you should use tag:v hvc1 to set it.
2023/09/21 07:06:37.411455 [HLS] ffmpeg: ch123.1-dANY-ip192.168.0.17-remux: [mpegts @ 0000000003d5bbc0] Stream 1, codec ac4, is muxed as a private data stream and may not be recognized upon reading.
2023/09/21 07:06:51.590189 [HLS] Stopping transcoder session ch123.1-dANY-ip192.168.0.17 (out=18.852178s finished=false first_seq=1 last_seq=18)
2023/09/21 07:06:51.603293 [TNR] Closed connection to 10A03099/0 for ch123.1 WUCW
2023/09/21 07:06:51.628309 [SNR] Statistics for ch123.1 WUCW: ss=95%-96% snq=100% seq=100% pps=388,210-462
2023/09/21 07:06:51.628309 [SNR] Buffer statistics for ch123.1 WUCW: buf=0% drop=0%
3 Likes
Progress! It seems to point to the decision on transcode or not falling over or retrying being in play. Interesting, and definitely food for thought for the devs here.
I'm assuming ATSC1 takes ~5 secs with HLS on, too?
2 Likes