Thanks for your response, but I respectfully disagree with that assessment.
This issue is not about unsupported hardware or “customer equipment” behavior—it points to a flaw in how the Fibe TV app handles telemetry failures. Through testing, I was able to isolate the problem to blocked requests to New Relic endpoints. When those requests fail (due to standard network-level privacy filtering), the app progressively degrades over time until it becomes barely usable. Force quitting temporarily resets the state, which strongly suggests improper handling of failed or retrying network calls.
To be clear, New Relic is not an advertising platform—it’s an observability/telemetry tool. Blocking it is a common privacy practice and should not break core app functionality. A production app should degrade gracefully when telemetry endpoints are unreachable, not enter a state of increasing latency and instability.
Also, this is not about ads funding the service. Ads in the TV experience continue to display normally. This is about background data collection endpoints impacting performance when unreachable. These are two separate concerns.
As a developer myself, this looks like a classic case of unbounded retries or blocking calls tied to telemetry. If New Relic experiences downtime or connectivity issues, this could potentially impact all users—not just those running network-level filtering.
I’m not asking for support of my specific setup, but rather highlighting what appears to be a robustness issue in the app itself. It would be worth escalating this to the development team for investigation, as it affects reliability and user experience.
Thanks.
