This means the HDHR stopped sending video data all of a sudden. Could be either a tuner issue or something happening on the network.
Are the HDHR and Apple TV plugged into the same switch now or different switches?
Hmm…
I’m using 2 Netgear Orbi with ethernet backhaul.
In case it was those, I put a switch at each end, and just had a single ethernet cable from each Orbi to the switch instead.
Everything else on the Apple TV plays just fine.
Recordings from the Channels DVR play just fine too - however the tuner and the DVR are on the same switch.
Nothing else appears to be affected on the network, so it’s a bit strange.
Think I’ll fire up Plex DVR and try via that and see how I get on.
1 Like
Plex transcodes all content at the server. If you want to do that with the DVR you can enable the transcoding option under Home Quality in Channels, which will make the DVR stream and not the app.
A better direct comparison would be with free apps InstaTV or VLC
1 Like
It appears to be an issue with Netgear Orbi when in ethernet backhaul mode - at least so far that is what I am leaning towards.
Even with the Orbi units just plugged into the switches it still causes the freezes - as though it is flooding the network or something similar. There were issues previously with ethernet backhaul mode but recent firmware has supposedly fixed those, so I dunno!
I’ll do some more troubleshooting today, but it can take a while for it to happen, so it’s a waiting game!
1 Like
I’m more baffled now. I tried InstaTV (horrible app!) and it worked just fine.
I’ve just been prompted with a firmware update 20180327 for the HDHomerun which seems odd, since it looks like it is from March and I have checked recently for firmware updates and none were available!
I’ve updated the firmware and back on Channels and it has just frozen again.
When it froze I checked the HDHomerun and none of the tuners were tuned.
HDHomerun log shows this (Apple TV is 192.168.1.111) - any idea?
19700101-00:00:01 System: reset reason = firmware upgrade
19700101-00:00:02 System: network link 100f
19700101-00:00:04 System: ip address obtained: 192.168.1.114 / 255.255.255.0
20180704-12:27:02 System: time changed from Thu Jan 1 00:00:20 1970 to Wed Jul 4 12:27:02 2018
20180704-12:28:47 Tuner: tuner0 streaming udp to 192.168.1.111:2003
20180704-12:29:06 Tuner: tuner0 udp stream ended (remote closed)
20180704-12:29:15 Tuner: tuner3 tuning 102 BBC TWO HD (tt8qam256:738MHz-17472)
20180704-12:29:16 Tuner: tuner3 streaming http to 192.168.1.111:49282
20180704-12:29:16 Tuner: tuner3 lockkey forced release by 192.168.1.111
20180704-12:37:01 Tuner: tuner3 http stream ended (remote closed)
This post is the exact same symptoms that I have and we are running the same version of Channels & tvOS 12.
Of course it could be a tvOS 12 issue, and therefore may get resolved.
1 Like
Ignore this for now.
I have removed the ethernet backhaul on the Orbi and it has been fine so far - although it means I will need to get another Orbi satellite for full coverage.
I’ll come back if the problem reoccurs, but looks like Netgear Orbi is the culprit at the moment!
1 Like
Glad you got to the bottom of this!
It looks like from the HDHR Log you posted that InstaTV is using UDP streaming instead of the better/modern HTTP method. So I guess VLC is the best comparison app.
I’ve heard other reports of problems with Orbi but it’s good to know the problem happens specifically with the Ethernet backhaul.
The HDHR log was from using Channels…
I haven’t used InstaTV since I did the firmware update on the HDHomerun - which can also be seen in the log.
The log shows 1) firmware upgrade, 2) UDP stream from tuner0 to the Apple TV, 3) http stream from tuner3 to Apple TV (Channels)
Unless InstaTV was doing something in the background?
After the firmware update, I only used Channels.
Since removing the ethernet backhaul, I have had the tennis on all afternoon and it has been rock solid 
I’ve ordered another Orbi satellite so I can use the 5Ghz backhaul instead. Sigh!
1 Like
Sooo…
I had to put the ethernet backhaul back because my little lad was whining so much about the wifi barely reaching his room!
I disabled daisy chaining on the Orbi and have had no freezes so far - however, I am getting occasional audio drop outs, but the picture is perfect and continues to play.
There is nothing in the Channels log when this happens, nor is there anything in the HDHomerun log.
How can I troubleshoot this?
I am curious if you are still experiencing these issues. I started having a bunch of issues with my Channels app as soon as I installed the Orbi mesh system (RBK50). I also used a wired backhaul. After reading this thread, I removed the wired backhaul and my system has been working flawlessly since then.
1 Like
@psykix I too am curious if you have permanently resolved this issue. I appear to be experiencing the same problem [ posted here - Losing connection a lot today ]. I have the Orbi RBK53 system. Just wondering if you have any advice.
1 Like
Hi. I don't think I can troubleshoot this issue any further without assistance. Any and all help would be appreciated. Apologies in advance if this is too much for an initial post but wanted to be thorough based on reading the previous posts.
I am also having this issue with my Channels app over an Orbi network. I receive Connection Lost errors multiple times a day while trying to watch live TV using Channels DVR app on an Apple TV 4k. When I get frustrated enough with the issue, I just watch the stream coming from the HDHomeRun Extend directly on my LG TV. Sometimes the LG has a minor hiccup and it spins for a second or two but then the stream returns to playing without exception. (With the Channels app I would have received the Connection Lost message and had to back up to the guide and reselect the channel to continue watching the program.)
I have changed the settings on my Orbi router to mimic the configuration described in the posts above to the best of my ability. I have also pulled logs that I have replicated below.
So here is what I’m running.
Orbi RBR50 — Orbi AC3000 Tri-band WiFi Router with Firmware Version V2.2.1.210. Backhaul Topology/Daisy-Chain Topology, Implicit Beamforming, MU-MIMO and Fast Roaming are all disabled. WMM (Wi-Fi multimedia) settings are enabled for both the 2.4 and 5GHz networks.
HDHomeRun EXTEND with an antenna for OTA and HDHomeRun Premium TV Channels
Model: HDTC-2US
Firmware: 20180817
Transcode configuration set to Heavy
Tuner Sharing is Off
Apple TV 4K running tvOS 12.1.1 (16K45)
I’m using the tvOS Channels DVR app (version 3.2.10) and running the Channels DVR (v2018.11.20.2224) on a Mac Mini. I have not experienced or at least noticed any lost connection issues with respect to recorded programming.
Channels DVR log (from Mac Mini where “10592E5D” is the Device ID of my HDHomeRun Extend)
2019/01/13 17:21:04 [TNR] Opened connection to 10592E5D for ch1113 [transcode=heavy]
2019/01/13 18:27:24 [DVR] Cancelling stream 10592E5D ch1113 after 3s read timeout
2019/01/13 18:27:24 [TNR] Closed connection to 10592E5D for ch1113
2019/01/13 18:28:48 [TNR] Opened connection to 10592E5D for ch1113 [transcode=heavy]
2019/01/13 22:32:20 [DVR] Cancelling stream 10592E5D ch1113 after 3s read timeout
2019/01/13 22:32:20 [TNR] Closed connection to 10592E5D for ch1113
2019/01/13 22:34:49 [TNR] Opened connection to 10592E5D for ch1113 [transcode=heavy]
2019/01/13 23:07:33 [TNR] Closed connection to 10592E5D for ch1113
HDHomeRun Extend log where “192.168.1.14” is the Mac Mini
20190113-22:21:04 Tuner: tuner0 streaming http to 192.168.1.14:56535
20190113-23:27:24 Tuner: tuner0 http stream ended (remote closed)
20190113-23:28:46 Tuner: tuner0 requesting 1113 MSNBC
20190113-23:28:48 Tuner: tuner0 streaming http to 192.168.1.14:56708
20190114-03:32:20 Tuner: tuner0 http stream ended (remote closed)
20190114-03:34:47 Tuner: tuner0 requesting 1113 MSNBC
20190114-03:34:49 Tuner: tuner0 streaming http to 192.168.1.14:57481
20190114-04:07:33 Tuner: tuner0 http stream ended (remote closed)
Apple TV / Channels DVR app log [http://192.168.1.31:57000/log]
2019-01-13 18:27:22.643 event: unpause
2019-01-13 18:27:22.645 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:27:22.648 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:27:24.212 read got (55) No buffer space available
2019-01-13 18:27:24.215 read got (55) No buffer space available
2019-01-13 18:27:24.217 read got (55) No buffer space available
2019-01-13 18:27:24.219 read got (55) No buffer space available
2019-01-13 18:27:24.221 read got (55) No buffer space available
2019-01-13 18:27:24.223 read got (55) No buffer space available
2019-01-13 18:27:24.225 read got (55) No buffer space available
2019-01-13 18:27:24.227 read got (55) No buffer space available
2019-01-13 18:27:24.229 read got (55) No buffer space available
2019-01-13 18:27:24.231 read got (55) No buffer space available
2019-01-13 18:27:24.233 read got (55) No buffer space available
2019-01-13 18:27:24.235 read got (55) No buffer space available
2019-01-13 18:27:24.237 read got (55) No buffer space available
2019-01-13 18:27:24.239 read got (55) No buffer space available
2019-01-13 18:27:24.241 read got (55) No buffer space available
2019-01-13 18:27:24.243 read got (55) No buffer space available
2019-01-13 18:27:24.245 read got (55) No buffer space available
2019-01-13 18:27:24.247 read got (55) No buffer space available
2019-01-13 18:27:24.249 read got (55) No buffer space available
2019-01-13 18:27:24.250 read got (55) No buffer space available
2019-01-13 18:27:24.252 streamer stopping after 685800 packets and 20 timeouts (73370 waits)
2019-01-13 18:27:24.279 [lavf] v: EOF reached.
2019-01-13 18:27:24.284 event: unpause
2019-01-13 18:27:24.286 [cplayer] v: End buffering (waited 1.656180 secs) [0.066733s].
2019-01-13 18:27:24.288 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:27:24.420 [af] v: filter input EOF
2019-01-13 18:27:24.422 [af] v: filter output EOF
2019-01-13 18:27:24.424 [cplayer] v: audio EOF reached
2019-01-13 18:27:24.541 [vf] v: filter input EOF
2019-01-13 18:27:24.543 [vf] v: filter output EOF
2019-01-13 18:27:24.583 [cplayer] v: video EOF reached
2019-01-13 18:27:24.584 [cplayer] v: EOF code: 1
2019-01-13 18:27:24.586 event: audio-reconfig
2019-01-13 18:27:24.588 event: video-reconfig
2019-01-13 18:27:24.589 [ad] v: Uninit decoder.
2019-01-13 18:27:24.591 [vd] v: Uninit decoder.
2019-01-13 18:27:24.599 event: tracks-changed
2019-01-13 18:27:24.618 event: end-file
2019-01-13 18:27:24.623 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateError
2019-01-13 18:27:24.629 event: audio-reconfig
2019-01-13 18:27:24.630 event: video-reconfig
2019-01-13 18:27:24.632 [cplayer] v: finished playback, success (reason 0)
2019-01-13 18:27:24.633 [cplayer] info:
2019-01-13 18:27:24.635 [cplayer] v: Set property: aid=1 -> 1
2019-01-13 18:27:24.637 [cplayer] v: Set property: audio=1 -> 1
2019-01-13 18:27:24.639 [cplayer] v: Set property: sid=0 -> 1
2019-01-13 18:27:24.641 [cplayer] v: Set property: sub=0 -> 1
2019-01-13 18:28:42.025 [cplayer] v: Set property: pause=false -> 1
2019-01-13 18:28:42.030 Updating playState from LTVideoPlayerPlayStateError to LTVideoPlayerPlayStateStopped
2019-01-13 18:28:42.041 Guide Loaded: {
Filter = "All Channels";
Source = Guide;
}
2019-01-13 18:28:42.618 Guide View (Main View/GuideView): (null)
2019-01-13 18:28:46.305 Updating playState from LTVideoPlayerPlayStateStopped to LTVideoPlayerPlayStateStopped
2019-01-13 18:28:46.307 [cplayer] v: Set property: pause=false -> 1
2019-01-13 18:28:46.349 Updating playState from LTVideoPlayerPlayStateStopped to LTVideoPlayerPlayStateLoading
2019-01-13 18:28:46.351 set streaming buffer to 128 segments (free bytes: 33951707136)
2019-01-13 18:28:46.353 Play Channel: {
Source = "Guide View Item Cell";
}
2019-01-13 18:28:46.355 streamer sent request to DVR 192.168.1.14: device 10592E5D, channel <HRChannel:0x280edebe0 number=1113 name=MSNBC (MSNBC)> [/devices/10592E5D/channels/1113/stream.mpg?codec=copy&transcode=heavy]
2019-01-13 18:28:46.886 Video View (Main View/VideoView): (null)
2019-01-13 18:28:48.348 event: start-file
2019-01-13 18:28:48.353 Updating playState from LTVideoPlayerPlayStateLoading to LTVideoPlayerPlayStateLoading
2019-01-13 18:28:48.355 [cplayer] info: Playing: cb://1547422126349
2019-01-13 18:28:48.357 [stream_callback] v: Opening cb://1547422126349
2019-01-13 18:28:48.359 [demux] v: Trying demuxers for level=force.
2019-01-13 18:28:48.946 streamer started receiving data
2019-01-13 18:28:48.955 [lavf] v: Found 'mpegts' at score=50 size=2048.
2019-01-13 18:28:48.957 [lavf] v: avformat_open_input() finished after 2048 bytes.
2019-01-13 18:28:48.959 event: tracks-changed
2019-01-13 18:28:48.968 event: tracks-changed
2019-01-13 18:28:49.020 event: metadata-update
2019-01-13 18:28:49.022 event: audio-reconfig
2019-01-13 18:28:49.024 event: audio-reconfig
2019-01-13 18:28:49.026 event: file-loaded
2019-01-13 18:28:49.028 event: audio-reconfig
2019-01-13 18:28:49.030 event: video-reconfig
2019-01-13 18:28:49.032 event: unpause
2019-01-13 18:28:49.034 event: tracks-changed
2019-01-13 18:28:49.036 event: video-reconfig
2019-01-13 18:28:49.038 event: playback-restart
2019-01-13 18:28:49.040 Updating playState from LTVideoPlayerPlayStateLoading to LTVideoPlayerPlayStatePlaying
2019-01-13 18:28:49.042 [lavf] v: avformat_find_stream_info() skipped
2019-01-13 18:28:49.044 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:28:49.046 [demux] v: Detected file format: mpegts (libavformat)
2019-01-13 18:28:49.048 [cplayer] v: Opening done: cb://1547422126349
2019-01-13 18:28:49.050 [lavf] v: select track 0
2019-01-13 18:28:49.052 [lavf] v: select track 1
2019-01-13 18:28:49.054 [cplayer] info: (+) Video --vid=1 (h264)
2019-01-13 18:28:49.056 [cplayer] info: (+) Audio --aid=1 (aac)
2019-01-13 18:28:49.058 [vd] v: Container reported FPS: 0.000000
2019-01-13 18:28:49.060 [vd] v: Codec list:
2019-01-13 18:28:49.062 [vd] v: h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
2019-01-13 18:28:49.064 [vd] v: Opening decoder h264
2019-01-13 18:28:49.066 [vd] v: Not trying to use hardware decoding: codec h264 is not on whitelist.
2019-01-13 18:28:49.068 [vd] v: Using software decoding.
2019-01-13 18:28:49.070 [vd] v: Detected 3 logical cores.
2019-01-13 18:28:49.072 [vd] v: Requesting 4 threads for decoding.
2019-01-13 18:28:49.074 [vd] v: Selected codec: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)
2019-01-13 18:28:49.076 [vf] v: User filter list:
2019-01-13 18:28:49.078 [vf] v: lavfi (lavfi.00)
2019-01-13 18:28:49.080 [ad] v: Codec list:
2019-01-13 18:28:49.082 [ad] v: aac - AAC (Advanced Audio Coding)
2019-01-13 18:28:49.084 [ad] v: aac_fixed (aac) - AAC (Advanced Audio Coding)
2019-01-13 18:28:49.086 [ad] v: aac_at (aac) - aac (AudioToolbox)
2019-01-13 18:28:49.088 [ad] v: Opening decoder aac
2019-01-13 18:28:49.090 [ad] v: Requesting 1 threads for decoding.
2019-01-13 18:28:49.092 [ad] v: Selected codec: aac (AAC (Advanced Audio Coding))
2019-01-13 18:28:49.094 [af] v: User filter list:
2019-01-13 18:28:49.096 [af] v: (empty)
2019-01-13 18:28:49.098 [cplayer] v: Starting playback...
2019-01-13 18:28:49.100 [af] v: [in] 48000Hz stereo 2ch floatp
2019-01-13 18:28:49.102 [af] v: format changed, draining filter chain
2019-01-13 18:28:49.104 [af] v: done format change draining
2019-01-13 18:28:49.106 [af] v: probing new format
2019-01-13 18:28:49.108 [af] v: [userspeed] 48000Hz stereo 2ch floatp
2019-01-13 18:28:49.110 [af] v: [convert] 48000Hz stereo 2ch floatp
2019-01-13 18:28:49.112 [af] v: got output format from probing
2019-01-13 18:28:49.114 [ao] v: Trying audio driver 'audiounit'
2019-01-13 18:28:49.116 [ao/audiounit] v: requested format: 48000 Hz, stereo channels, floatp
2019-01-13 18:28:49.118 [ao/audiounit] v: using soft-buffer of 9600 samples.
2019-01-13 18:28:49.120 [cplayer] info: AO: [audiounit] 48000Hz stereo 2ch floatp
2019-01-13 18:28:49.122 [cplayer] v: AO: Description: AudioUnit (iOS)
2019-01-13 18:28:49.124 [vd] v: Decoder format: 1280x720 yuv420p auto/auto/auto/auto/auto CL=mpeg2/4/h264 (auto 0.000000/0.000000/0.000000)
2019-01-13 18:28:49.126 [vf] v: [in] 1280x720 yuv420p bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
2019-01-13 18:28:49.128 [vf] v: [userdeint] 1280x720 yuv420p bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
2019-01-13 18:28:49.130 [vf] v: [lavfi] 1280x720 yuv420p bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
2019-01-13 18:28:49.132 [vf] v: [autorotate] 1280x720 yuv420p bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
2019-01-13 18:28:49.134 [vf] v: [convert] 1280x720 yuv420p bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
2019-01-13 18:28:49.136 [cplayer] info: VO: [libmpv] 1280x720 yuv420p
2019-01-13 18:28:49.138 [cplayer] v: VO: Description: render API for libmpv
2019-01-13 18:28:49.140 [vo/libmpv] v: reconfig to 1280x720 yuv420p bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
2019-01-13 18:28:49.142 [cplayer] v: first video frame after restart shown
2019-01-13 18:28:49.144 [cplayer] v: Enter buffering (buffer went from 100% -> 30%) [0.300300s].
2019-01-13 18:28:49.146 [cplayer] info: (+) Video --vid=1 (h264)
2019-01-13 18:28:49.148 [cplayer] info: (+) Audio --aid=1 (aac)
2019-01-13 18:28:49.150 [cplayer] info: Subs --sid=1 (*) (eia_608)
2019-01-13 18:28:49.152 [cplayer] v: starting audio playback
2019-01-13 18:28:49.154 [cplayer] v: playback restart complete
2019-01-13 18:28:50.175 event: unpause
2019-01-13 18:28:50.181 [cplayer] v: End buffering (waited 0.913696 secs) [1.201200s].
2019-01-13 18:28:50.189 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:29:33.992 event: unpause
2019-01-13 18:29:33.994 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:29:33.997 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:29:34.095 event: unpause
2019-01-13 18:29:34.098 [cplayer] v: End buffering (waited 0.104467 secs) [1.534867s].
2019-01-13 18:29:34.100 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:29:35.654 event: unpause
2019-01-13 18:29:35.656 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:29:35.659 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:29:36.082 event: unpause
2019-01-13 18:29:36.087 [cplayer] v: End buffering (waited 0.415240 secs) [1.835167s].
2019-01-13 18:29:36.102 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:29:55.272 [ad] warn: Invalid audio PTS: 78150.189089 -> 78151.767756
2019-01-13 18:29:55.274 [cplayer] warn:
2019-01-13 18:29:55.277 [cplayer] warn: Audio/Video desynchronisation detected! Possible reasons include too slow
2019-01-13 18:29:55.279 [cplayer] warn: hardware, temporary CPU spikes, broken drivers, and broken files. Audio
2019-01-13 18:29:55.281 [cplayer] warn: position will not match to the video (see A-V status field).
2019-01-13 18:29:55.282 [cplayer] warn:
2019-01-13 18:34:55.205 event: unpause
2019-01-13 18:34:55.208 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:34:55.212 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:34:55.415 event: unpause
2019-01-13 18:34:55.416 [cplayer] v: End buffering (waited 0.200890 secs) [1.634967s].
2019-01-13 18:34:55.423 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:35:31.619 event: unpause
2019-01-13 18:35:31.622 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:35:31.625 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:35:31.808 event: unpause
2019-01-13 18:35:31.810 [cplayer] v: End buffering (waited 0.193390 secs) [1.901900s].
2019-01-13 18:35:31.813 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:36:24.376 event: unpause
2019-01-13 18:36:24.378 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:36:24.381 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:36:25.015 event: unpause
2019-01-13 18:36:25.019 [cplayer] v: End buffering (waited 0.629029 secs) [2.302300s].
2019-01-13 18:36:25.032 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:46:43.744 [ffmpeg/audio] error: aac: skip_data_stream_element: Input buffer exhausted before END element found
2019-01-13 18:46:43.746 [ad] error: Error decoding audio.
2019-01-13 18:46:43.749 [ffmpeg/audio] error: aac: channel element 2.9 is not allocated
2019-01-13 18:46:43.751 [ad] error: Error decoding audio.
2019-01-13 18:47:42.557 event: unpause
2019-01-13 18:47:42.559 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:47:42.562 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:47:42.828 event: unpause
2019-01-13 18:47:42.830 [cplayer] v: End buffering (waited 0.253421 secs) [2.769433s].
2019-01-13 18:47:42.833 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:58:30.342 event: unpause
2019-01-13 18:58:30.345 [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2019-01-13 18:58:30.347 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:58:32.967 event: unpause
2019-01-13 18:58:32.970 [cplayer] v: End buffering (waited 2.524862 secs) [5.405400s].
2019-01-13 18:58:32.994 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:58:33.021 [ad] warn: Invalid audio PTS: 79865.495756 -> 79870.829089
2019-01-13 18:58:33.022 [cplayer] v: Reset playback due to audio timestamp reset.
2019-01-13 18:58:33.107 [vd] v: Decoder format: 1280x720 yuv420p auto/auto/auto/auto/auto CL=mpeg2/4/h264 (auto 0.000000/0.000000/0.000000)
2019-01-13 18:58:33.111 [cplayer] v: first video frame after restart shown
2019-01-13 18:58:33.114 event: unpause
2019-01-13 18:58:33.116 event: playback-restart
2019-01-13 18:58:33.118 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStatePlaying
2019-01-13 18:58:33.120 [cplayer] v: Enter buffering (buffer went from 100% -> 44%) [0.448000s].
2019-01-13 18:58:33.122 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2019-01-13 18:58:33.124 [cplayer] v: playback restart complete
2019-01-13 18:58:33.970 event: unpause
2019-01-13 18:58:33.972 [cplayer] v: End buffering (waited 0.827938 secs) [1.002667s].
2019-01-13 18:58:34.007 Updating playState from LTVideoPlayerPlayStateBuffering to LTVideoPlayerPlayStatePlaying
2019-01-13 18:58:37.531 [cplayer] v: starting audio playback
2019-01-13 19:20:17.160 Notification: LTGuideDataUpdated
2019-01-13 19:32:10.080 [ffmpeg/audio] error: aac: TYPE_FIL: Input buffer exhausted before END element found
2019-01-13 19:32:10.083 [ad] error: Error decoding audio.
2019-01-13 19:32:10.085 [ffmpeg/audio] error: aac: Reserved bit set.
2019-01-13 19:32:10.087 [ffmpeg/audio] error: aac: Number of scalefactor bands in group (52) exceeds limit (49).
2019-01-13 19:32:10.089 [ad] error: Error decoding audio.
2019-01-13 20:20:16.899 Notification: LTGuideDataUpdated
@awrtwenty15, It is interesting that you're using a Mac as your DVR. At the time of my post, I was also using a Mac. I don't know if that is related or just a coincidence. A week or so ago, I moved my Channels DVR from my Mac over to a Synology NAS. So far, I have not had the connection lost problem. But when it did happen, it would go for days and remain perfectly stable, and then one day everything would go to crap. Long story short, moving it off the Mac may or may not have fixed the issue for me. Time will tell!
You used to have the "connection lost" issue watching Live TV, but it (apparently) stopped when you changed your DVR platform?
@awrtwenty15, sorry, I don't know the Orbi hardware/setup and I really do not have the time right now to do the research necessary to understand it well enough to comment on the reasonableness of your configuration, so all I can offer are some general observations:
#1 - It has been my observation that Orbi mesh networks are nothing but trouble for high-bandwidth video streaming. Particularly Live TV. Double particularly if people try to use them between HDHR tuners and DVRs.
#2 - HDHR tuners must always be hard-wired
#3 - DVRs must always be hard-wired
#4 - You should *never use WiFi routers, or any routers, actually, or the Ethernet ports on wireless mesh devices, between HDHR tuners and DVRs, but instead always use quality Ethernet switches. (I like NetGear ProSafe. Others have had success with other manufacturers' products.)
#4a - The Common Recommendation is "connect them to the same switch," but my experience has been they don't have to be the same switches, as long as multiple switches are connected only to other switches. E.g.: HDHR tuner <-> switch <-> switch <-> DVR.
#5 - It may be ok to use wireless mesh systems for client devices. Then again it may not. YMMV.
#6 - Contrary to the beliefs on the parts of some: WiFi can be fine for clients. Even multiple clients. If it's a good WiFi system. Just the other day I had five clients (Amazon FireTV, two MiBox Android TVs, an Apple iPad and an Apple iPhone) streaming combinations of live and recorded HD content simultaneously via one WiFi access point. No problem.
Thank you both for your comments. They provide significant perspective and guidance with respect to my issues. @jseymour I appreciate and agree with your comments regarding hard wiring. I'd never given it that much consideration to intentionally put everything on the same switch or just to switches. That being said, I actually had somewhat inadvertently configured all of my HDHR, DVR and Apple TV that I watch most frequently on the same switch. Was definitely experiencing the the Connection Lost issues in that configuration though perhaps less often.
So I don't know if it's just a fluke or pure luck but I have not experienced a single Connection Lost issue today. Thought I was coming close a few times but - knock on wood - so far so good. It's kind of lame but the only delta between yesterday and today is a quick change I made when describing and thinking through my setup. I realized I had turned on Tuner Sharing on the HDHomeRun Extend when I initially installed everything. I decided that Tuner Sharing was not necessary based on my use case last night so I turned it off. I think everything else has remained constant since yesterday. Long story short - I have not experienced the issue in roughly 18 hours which is a big accomplishment. I don't know if turning off Tuner Sharing was the issue or just the straw that broke the camel's back on the problem but it is what it is.
I am hopeful the current config will sustain but I kind of doubt it. So continue to welcome any additional points of consideration. Thanks!
With tuner sharing on, the stream goes through the DVR which has a 3s timeout. No video data received for 3s = assumed disconnect. This is what you observed in your logs.
With tuner sharing off the app connects directly, and it looks like it has a 5s minimum timeout. Connecting directly also reduces the amount of traffic going through your switch by half, because the video doesn't need to go into and then back out of your DVR.