Issue where the tracking overlay will appear momentarily out of nowhere

Hey guys,

So I am looking for some advice on the best way to track this down. I have only noticed it on my 3 ATVs and luckily it is EXTREMELY intermittent, but still want to see if I can sort it out.

Basically, when watching something for an extended period of time, say a sports game, occasionally the tracking overlay will pop up, almost like someone tapped the remote. Something it will stutter for a split second before the overlay disappears and everything continues on like nothing happened. I have watched entire days worth of football where it only happens once or twice and I cannot seem to figure it out.

The ATVs are all wired and my network is strong. I checked the clients to make sure they are all locally connected. When I look at the stats, I don't see anything that stands out to me, except for a few dropped output frames (less than 10 over an hour plus of watching)

Just curious as to what I might be able to take a look at that would give me some clues into what is happening. Thanks for any tips!

1 Like

Sounds like a networking issue to me. Give some details:
DVR server
All ATV's homerun to the main network switch?
Which sources us this happening on? List all that apply
HDHR wired to the same switch?

Speedtest from your ATV? app will give some info even though it isn't a good measurement of local speed to the DVR. In other words is jitter way out there etc.

1 Like

Thanks for the reply and sorry for the admittedly poor post. Was hoping it might be something quick someone else was seeing.

I just updated to Channels 2023.02.05.1636 - haven't watched for long enough to see if that made a difference.

The server is running in a Docker container running Ubuntu 20.04 as a VM on Proxmox. I have a bunch of other services that I have not noticed any issues with.

The network setup is as follows. I have a UDM Pro as the main network controller which is connected to a USW Pro 24 port switch. The internet runs in to the WAN on the UDM from the ONT and then I have the UDM connected to the USW via SPF+. All of my devices that are hardwired are connected to the USW. All the ATVs are directly connected to the USW.

The only source I have is my HD Homerun Prime. I haven't used my Plex sever to watch LiveTV in while, in fact I hated that interface so much which is why I moved to channels, but I never had an issue like this when watching on Plex. The HDHR is wired to the same switch as the Proxmox box.

Lastly, I ran the speedtest on all the ATVs (they had similar results) -- 762Mbps Down/860Mpbs Up - Ping 7ms - Jitter 0.19ms - 0% Loss. I am not an expert, but I am an enthusiast and am pretty sensitive to issues with the network, and haven't noticed anything lately that could point me in the right direction.

My plan is to eventually rebuild the Proxmox box, as it kind of started as a test project but eventually as I started to build out the services I started to actually use them. I do wonder if starting fresh would resolve the issue, but I don't know when exactly I am going to get around to starting from the ground up.

As mentioned, the issue is extremely intermittent, but I do appreciate any ideas in how to maybe track it down.

Thanks again!

Not sure if this is your issue specifically but the way you describe this sounds like nested virtualization and as far as performance goes could be an issue

I agree I don't think your network is the problem. I bet it's a resource issue on the server. This is just speculation as logs will tell the story etc.

Is there a difference between watching live without tuner sharing enabled and watching pre-recorded content from the DVR? When you do not have tuner sharing enabled and you watch live tv, you are connecting direct from the ATV to the HDHR. If you cannot repro this problem in that scenario, then it zeros in on your DVR server.

I'm kind of a performance snob. If it were me I would grab an unused computer and ditch the VM/docker route and go traditional install. At the very least I would ditch the docker nested virtualization and just run your channels server on a dedicated Ubuntu server VM (without docker)

It could also be a glitch in the cable feed.

Very true and if you can repro with tuner sharing disabled then that would isolate it to the cable feed (or HDHR itself)

Thanks so much for detailed replies, I really do appreciate it. That is great advice about the tuner sharing setting to further determine where the problem might lie. I will definitely give that a look.

The funny thing is I never intended for Channels in docker to be my permanent solution. I had hacked together the Proxmox box to play around, as up to that point I had only had my TrueNas server and wanted to more freely play around with docker. Everything just went so well and I liked Channels so much that it became my families main LiveTV source.

I have upgraded the box and I think it should have the resources to handle Channels in its own Ubuntu VM, so I'll start with that.

Thanks again for the all the help, this gives me more than enough to tinker and try and track down the issue. Of course since I posted, I haven't seen it happen, as always seems to be with these things :slight_smile:

I have noticed this happening on my Channels setup too - Apple TV clients, only on HDHR channels (other m3u sources all fine). Play never stops, just the little banner appearing every now and then. Anecdotally I'd say it's been happening more often lately, but I haven't been keeping a log.

I have noticed that often it coincides with when i pickup an iPhone connected to the home network and have wondered whether it's doing something with some background remote control functionality but could just be coincidence.

HDHR and apple TV's hardwired to gigabit switch. Tuner sharing is enabled. Current stable version of ChannelsDVR running on Windows 10 machine i7 / 24GB RAM, dedicated channels use.

Try turning off tuner sharing and see if you can repeat the problem.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.