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.
@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.
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.
Having less issues with tuner sharing off does imply it’s a bandwidth issue on your network. Getting as much off of the WiFi and onto wired will likely help immensely.
You didn't mention any switch, previously. I'm curious: What make and model? Because it sounds to me like you have a network issue.
Correct. I have tuner sharing turned on, so everything is routed through the DVR. I'll post an update on this thread if the issue remains tamed, or if it comes back. Again, I'm not saying that the Mac was the cause; It was just an interesting coincidence.
The switch is an 8-port desktop gigabit switch made by TP-Link. Model TL-SG1008D V6.0. I have an 8-port Gb switch by MonoPrice (p/n 15763) sitting unused if a test might help glean something.
That being said, turning off tuner sharing has made a significant improvement. I experienced one Connection Lost event today (the one and only since turning tuner sharing off) but I can reliably say that issue was caused by my poor internet connection from Windstream.
My current LAN setup is honestly cringe worthy but I am not experiencing issues now that tuner sharing is off (for the avoidance of doubt the HDHR, DVR and AppleTV are no longer on the same switch). I purchased the HDHR Extend specifically because I was moving to a new apartment that was not wired for ethernet or even coax so I knew I would be relegated to wireless for at least some of my TV. Kind of wondering if the Extend is providing any benefit or if it was just extra money wasted...
Additionally, I have a 5 port Netgear ProSafe GS-105 v5 switch I could move around to test.
I've never been enamoured of TP-Link, though many report good results with much of their hardware. To each their own. As for the Monoprice switch: I like Monoprice. Use them for lots of things. Don't know diddly about their networking hardware. Would not be my choice, either.
That being said: I have a hard time believing just about any modern Ethernet switch wouldn't be able to handle HDHR tuner + DVR + client w/o bungling. With that being said: I might be inclined to try the HDHR tuner + DVR + client all connected to the NetGear switch. Our HDHR tuner and DVR are connected to one another via a GS105Ev2, which, in turn, is backhauled to an unmanaged 8-port NetGear switch. Clients are all on WiFi, the AP of which is plugged into the 8-port switch. (Currently, via a 5-port NetGear PoE switch, for testing.)
I don't believe I've ever seen "Connection lost" in any log.
I had this issue a lot. I think they must have fixed it behind the scenes because the last few days it hasn't happened at all for me. Apple TV, Netgear Orbi, and hardwired via ethernet.
Did your Orbi update firmware recently?
It updated on March 30th.
What could be the issue with the below error
2023/02/12 10:21:31.636685 [TNR] Opened connection to M3U-SJTV for ch80 IND: Sony 4K
2023/02/12 10:27:18.695328 [TNR] Error during live stream for ch80 IND: Sony 4K: Could not parse playlist: http://89.36.95.2:33049/live/27514924/31513300/586704.m3u8?token=HkRZV0YORFgTBgRbWgQDBF1QXgUEBVIABwJdAwpaD1xXAlcOB1ZUBFQXHBsQFUVRBFlnXwYWDAJcBg4ABk4UEBYDQ2lcAkRYEwMIDFtXAhZJFkxfD1EUDVQcG0BbBhRfR1cABgxRRE4TUEhNBhNZVQlrXFMUXVVSRgpXRV4OGkcKCG5SUAsHDFUXChtTQxsWDEdIFFhaQ1sIHBtSWxZEBBEDEwwXVVdXBRccGwAOQloRRkEUWBZ3ckYcG1VKFlMLFg9eWBdcRA8CQAgbT0NeRzpGXUUWRlNWCVVLEghABkdJRFxXTTkFDV9bVVoXCFhaFhYCFFMWGhUJX1dZRg1EOhUPVRQPRFJaBg=: <center><h2>cooldown and try again later, too many requests.<br><h4>How to fix ?</h4>
<p>If your line is restreamer probably you have to many wrong streams id in your server of 89.36.95.2:33049 source.
<br>Please optimize your server by remove all wrong or down 89.36.95.2:33049 source channels ids from your server channels list.<br>
Please note: 89.36.95.2:33049 never change there any stream id we always fix channel one by one, by edit and replace source to avoid any id change of any channel, thankyou.</p></center>: Can't detect playlist type
2023/02/12 10:27:18.695586 [SNR] Buffer statistics for 192.168.4.42 (Apple TV) for ch80 IND: Sony 4K: buf=0% drop=0%
2023/02/12 10:27:18.708912 [TNR] Closed connection to M3U-JTV for ch80 IND: Sony 4K