Keep the missing value
The XMLTV DTD makes stop optional. A missing stop is therefore not, by itself, a malformed programme entry. Preserve that absence in the raw import rather than immediately assigning a convenient fixed duration.
If the application needs an ending, label any inference. For an invented programme starting at 18:00 with the next accepted entry at 18:30, a next-start policy can propose 18:30 as its ending. That remains a policy-derived value, not a stop supplied by the feed.
Define the boundary cases
Apply a next-start inference only within the intended channel and accepted ordering. Specify what happens at the end of the available feed, across a gap, or when two entries share a start. A last programme should not silently inherit the next day's first start without review.
Do not substitute the programme's length field automatically. XMLTV distinguishes programme content length from a scheduled transmission interval that can include other material. A film's running time does not necessarily identify its schedule slot's ending.
Keep provenance in the downstream result
Store the chosen ending together with its derivation, source revision and confidence or review status. Then a later explicit stop can replace the inference without looking like an unexplained manual edit.
Show reviewers the affected programme intervals, not just that a default was applied. If the application cannot express an unknown ending honestly, that is an output-model decision to resolve. No duration in this article was taken from a real channel schedule.
Questions answered
Is a missing stop automatically a DTD validation error?
No. The field is optional in the XMLTV DTD.
Can running length always replace the missing stop?
No. Content length and scheduled slot length are different quantities.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.