XMLTV programme records use timestamps for scheduled airings. Start identifies when an entry begins; stop can identify its end. These are schedule values rather than a measurement of the stream arriving at your television. A few seconds of delivery delay should not be treated as a broken guide timestamp.
Read the complete timestamp
A timestamp can include year, month, day, time and a timezone offset. Looking only at the hour can hide a date or offset mistake. Midnight entries are especially easy to assign to the wrong day when comparing screenshots.
Keep duration and airtime distinct
A listed half-hour slot can include breaks or change because the broadcaster’s schedule changes. The difference between start and stop describes the slot represented by the guide. It does not guarantee a fixed downloadable file length.
Look for a consistent pattern
If every programme is shifted equally, investigate timezone handling before editing individual entries. If only one programme is wrong, the source schedule may need a correction. A pattern across many channels gives more useful evidence than one isolated title.
A practical sequence
- Read the date and timezone as well as the clock time.
- Compare several neighboring entries.
- Separate a uniform offset from one incorrect programme.
An example
A programme beginning at 23:30 and ending at 00:15 crosses a calendar boundary. Treating both times as the same date would create an invalid negative duration.
Questions about this topic
Is the stop value always a recording duration?
No. It describes schedule timing when supplied.
Does a live delivery delay require an EPG shift?
Usually not; a small stream delay is different from a schedule timezone error.
