We use cookies to understand how the site is used and to improve it. You can accept them, or carry on with them switched off.
Also known as: malformed nzb, invalid nzb
An NZB a client refuses to load because its XML is malformed, truncated by an interrupted download, or wrapped in an HTML error page the indexer served in place of the file. Segment entries lacking message-ids draw the same rejection. Re-downloading the NZB usually fixes it, and a file that fails twice points at an indexer problem rather than anything in the newsreader.
The parse failure is diagnostically valuable because of where it sits in the sequence. An NZB is an XML manifest listing Message-IDs, the groups each article was posted to, and segment byte counts; it carries no article data of its own. A client reads and validates that XML before it opens a single connection to a news server. A rejection at that point proves the provider, the account, and the network path were never exercised, which rules out roughly half of what a reader would otherwise start adjusting.
A loadable NZB is a well-formed XML document with an <nzb> root, at least one <file> element, and within each file a group list and a <segments> block whose entries each carry a Message-ID and a byte count. A <segment> element with no Message-ID text inside it is enough for a strict parser to refuse the document, even when everything around it is intact. Clients differ on how much damage they tolerate: some skip the broken file entry and load the remainder, others abort on the first fault, so the same file can load in one application and fail in another.
The most frequent cause involves no XML at all. The browser or download tool asked the indexer for the file, the indexer answered with a login prompt, a rate-limit notice, an API quota message, or a maintenance page, and what landed on disk is that HTML page saved under the requested name. Opening the file in a text editor settles it in seconds. A real NZB begins with an XML declaration and an <nzb> root; an error page begins with <!DOCTYPE html> and usually states the problem in plain language within a few lines. File size is the second tell, since these pages run to a few kilobytes where an NZB for a large release runs to hundreds.
A transfer cut short produces a file that parses correctly up to the break and then reaches end of input inside an open element, which parsers report as an unexpected end of document rather than as invalid markup. A full disk on the machine that saved the file produces exactly the same shape and is worth ruling out first. Encoding damage is the other variant: NZB files are UTF-8, and a file re-saved by an editor in another encoding, or reconstructed from a copy and paste that substituted typographic quotation marks for plain ones, can carry bytes the parser will not accept. Hand-editing an NZB to change a release name is a common way to introduce this.
One failed file is noise. Re-fetching the NZB from the same indexer clears most cases, because the underlying transfer simply failed once. A file that arrives broken twice, or several different releases arriving broken in the same session, points at the indexer: an expired session cookie, an exhausted API allowance, or a fault in how it generates NZBs. The provider supplies articles and has no role in producing this file, so no change to server settings, connection counts, or retention affects the outcome.
Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.