A text edit can become a structural error
An XML guide is structured text, so some characters have a special role. A literal ampersand in ordinary XML character data needs the correct representation, such as &, rather than being inserted as an unescaped delimiter. A newly edited programme title can therefore break parsing even when its words look perfectly reasonable in a spreadsheet or text editor.
Use this workflow for a guide you are authorised to prepare. Keep the last working export and the new export separately. If an import fails immediately after a content edit, preserve the parser's line, column and message where available. An account password change or EPG time offset does not repair malformed XML, so avoid mixing those interventions into the first check.
A hypothetical title update
Suppose a publisher changes a title from News Review to News & Review in its source data. A proper XML serializer should escape the character when writing the document. If a manual string-building step inserts the raw ampersand instead, the generated file may become invalid. This hypothetical example concerns the export method, not a prohibition on ampersands in programme titles.
Compare the generated XML around the reported error with the last working output. Use a safe editor and a small authorised sample. Do not remove every punctuation mark from the entire guide to make the import pass; that destroys useful content while concealing the broken escaping step. Correct the generator or serializer responsible for the output.
Avoid a second escaping mistake
A file that already contains & should not be blindly escaped again as ordinary source text. Double escaping can produce visible entity text instead of the intended ampersand. Keep a clear boundary between raw editorial strings and serialised XML. A serializer should receive the right form for its documented API rather than a mixture of pre-escaped and unescaped values.
Encoding is another separate check. The document's declared character encoding and actual bytes must agree, especially for names and accented text. Do not assume every garbled character is the same problem as an unescaped delimiter. Preserve the parser result and the rendered content so syntax, encoding and editorial accuracy can be investigated independently.
Validate before the full import
Run the corrected small output through the intended XML validation or parser workflow before replacing a production guide. Then inspect the imported title as the viewer sees it. A syntactically valid file can still show the wrong literal text, and a readable single title does not prove every channel reference or timestamp is correct. Use separate checks for those relationships.
Once the small case works, regenerate the complete authorised guide from the corrected publishing path. Keep a note of the failing field and repair so later editors do not repeat a manual workaround. The useful result is both valid structure and faithful programme text, achieved without changing unrelated account, network or time settings.
Questions answered
Must I remove ampersands from programme titles?
No. Preserve the intended title and encode it correctly when serialising XML.
Does a successful XML parse prove the whole guide is correct?
No. It establishes syntax acceptance. Check displayed text, identifiers, source edition and timing separately.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.