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.
Name the timeline first
A programme guide might list a broadcast at a local time, while a web player appends media frames at presentation timestamps. Those are different coordinate systems. An error that consistently places every guide event one hour late is different from an append boundary that produces overlapping frames. Record whether the complaint concerns the guide display, a subtitle cue or the actual position of media in playback.
Understand the developer setting
The MSE specification defines timestampOffset as an offset applied to timestamps in subsequently appended media segments. That is a media-buffer operation inside a player implementation. It is not a timezone selector for the household or a way to change the XMLTV source’s stated offset. An API property containing the word timestamp should not be reused merely because another system also represents time.
Work through two hypothetical reports
In the first case, a guide says 20:00 while a confirmed local schedule says 19:00; the video itself is otherwise steady. In the second, a player developer finds a boundary problem when joining authorised media pieces whose presentation timelines do not align. These reports need different investigations. Altering a player’s media timeline to hide the guide’s one-hour error could introduce playback problems while leaving the schedule data unchanged.
Preserve the boundary between user and developer controls
A viewer should report the exact displayed schedule, date, timezone and observed programme, without changing undocumented application internals. A player developer should inspect the actual appended timestamps and buffer state. Neither task requires inventing the other system’s values. This distinction supports a precise report and avoids calling every time-related setting an EPG fix or a general cure for subtitle drift.