A byte order mark is an invisible marker some editors place at the start of a text file. Reader tolerance varies. If a local playlist looks correct but a strict parser rejects its opening header, the file’s encoding and leading bytes are worth inspecting before rewriting every entry.
Keep the symptom narrow
A leading-marker issue normally affects recognition at the beginning of the file. It does not explain an isolated channel failing after the entire list imported successfully. Match the proposed repair to the stage that actually failed.
Use an encoding-aware editor
A plain-text editor may offer UTF-8 with or without a BOM. Save a separate test copy using the format required by the reader. Keep all visible playlist text unchanged so the comparison isolates the encoding difference.
Do not remove arbitrary invisible characters
A broad cleanup can alter legitimate non-English text or password values. Work on a copy and inspect the actual opening bytes where possible. A source-generated file should be corrected through the service if it repeatedly arrives in an incompatible form.
A practical sequence
- Keep an untouched original.
- Inspect the file’s encoding and opening marker.
- Test a copy in the reader’s documented text format.
An example
Two files can display the same #EXTM3U header in an editor while differing in invisible bytes before it. A strict reader may accept only one of them.
Questions about this topic
Will this fix a channel that already imported?
Not usually. Header recognition has already succeeded in that case.
Should every invisible character be deleted?
No. Use a targeted encoding correction.
