Media diagnostics · Primary-source explanation; examples are illustrative. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Identify the field before interpreting it
A diagnostic overlay can display a changing processor frequency during a video and tempt a quick conclusion that the device is overheating. The Linux CPUFreq documentation gives a more careful interpretation. The scaling_cur_freq attribute often reflects the last performance state requested by the driver and may not equal the exact hardware frequency at that instant. Other fields describe allowed limits or hardware derived feedback. Retain the field name instead of reporting an unexplained clock number.
Compare the same workload
For an original observation plan, record the field, relevant policy and playback symptom while the same permitted local sample runs. Note whether the computer is on battery power, whether the workload changes and what other applicable telemetry is available. A lower requested state during a quiet passage is not by itself evidence of a fault. A visible stall occurring at the same time warrants further investigation, but timing correlation alone does not establish its cause.
Do not force maximum performance as a diagnosis
The documentation describes performance and power tradeoffs and platform specific driver behaviour. Changing governors or limits before collecting the baseline can remove context and introduce other effects. Keep observation separate from any later justified configuration experiment. This article concerns interpretation of Linux telemetry; it does not provide a universal safe clock setting, claim measured thermal behaviour for a TV box, or promise that processor frequency explains a network buffering event.