Media diagnostics · Primary-source explanation; examples are illustrative. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Separate the request from the delivery schedule
A web recording tool may ask MediaRecorder to deliver data in one second slices. MDN warns that the actual dataavailable timing is not exact: pending work and browser specific behaviour can delay delivery and produce larger chunks. Therefore counting received chunks is not a reliable stopwatch. This matters when a support utility reports an apparently short recording even though the viewer remembers leaving it running considerably longer.
Work through an uneven example
Imagine a permitted local test whose chunk notifications arrive at one, two, five and six seconds after recording begins. Four delivered objects do not establish four seconds of total activity. The gap might include data delivered later. These invented values demonstrate the counting error; they do not predict any browser schedule. Keep a separate elapsed timer and record the event timestamps so the report preserves both wall time and delivery timing.
Finish and inspect the recording
Stopping the recorder delivers remaining captured material through the documented event path. Preserve that final data before declaring the file complete. Inspect the resulting duration and whether its end contains the intended test action, rather than judging solely from the last notification time. Use only material you are entitled to record. A chunk timing observation describes the browser recorder and does not establish a remote service recording allowance, successful cloud storage, or preservation of protected media.