Media diagnostics · Primary-source explanation; no UK IPTV implementation or account test. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
A clean recent interval can follow an earlier problem
Imagine a receiver that has counted forty missing packets during a long RTP source session. Its next report interval expects one thousand more packets, and all arrive. The recent interval has no newly observed loss, while the cumulative count can still show forty. That is a coherent report: an earlier problem remains in the session history. Conversely, a small lifetime ratio can conceal a poor recent interval when a long clean period preceded it. These values are invented to illustrate the reporting scopes.
Read the RTCP fields as different questions
RFC 3550 distinguishes a fraction lost for the interval since the previous report from a cumulative packet count. The fraction field also has a specific fixed-point representation; a raw byte is not automatically a decimal percentage. A monitoring application may perform that conversion before display. Establish whether the interface is showing the protocol field, its conversion, or a separately calculated dashboard metric. Keep the relevant source identity and report boundaries, because a restarted or changed source can invalidate a simple comparison across screens.
Report the change without erasing history
For a useful support note, describe both the recent interval and the cumulative values with their times. Avoid announcing that the connection has never lost packets merely because the latest interval is clean. Avoid announcing that it is currently losing packets solely because an old count remains nonzero. The practical question is whether new evidence appeared during the observed symptom. This article explains base RTCP reporting semantics; it does not assert that a particular UK IPTV player exposes these fields or that all streaming protocols use them.