Empty NZB

This is the quieter of the two NZB faults, because no error is raised anywhere. The XML is valid, the client accepts the job, and there is simply nothing to request. Depending on the client the entry appears and disappears within a second, lands in history marked complete at zero bytes, or is flagged failed at the post-processing stage when the unpacker finds no files to work on. None of those messages names the actual condition, which is why the file itself has to be inspected.

What is missing from the document

Two shapes produce this. The document may have a valid <nzb> root with no <file> children at all, or it may list file entries whose <segments> blocks contain no segment elements. Both are well-formed XML and both parse without complaint. Neither gives the client a Message-ID to ask for, so no ARTICLE or BODY command is ever issued. Opening the file in a text editor and searching for the string segment is the entire diagnosis: an NZB for a multi-gigabyte release contains thousands of those lines, and one that contains none is empty in the sense meant here regardless of how large the surrounding metadata makes it look.

The fault sits with the indexer

The division of labour is clean. The indexer scans group headers, groups articles into releases, and writes the Message-ID list into the NZB; the provider serves articles when a client asks for them by Message-ID. An NZB with no segments means the indexer had no Message-IDs to write, so the provider is never consulted and cannot be responsible for the result.

The usual origins are a release whose articles are no longer held by any server, with the index entry left in place; a subject-parsing run that failed partway and recorded a release name with an empty article list; and an API error document returned in place of a file once a request quota was exhausted. The quota case is worth checking first when every grab from one indexer started failing at the same moment, since it affects all releases at once rather than a single one.

Why retrying is the wrong response

Re-grabbing reproduces the file exactly, because it is regenerated from the same database rows each time. The result changes only if the indexer re-scans and repopulates the release, which is outside the reader's control. Where the same release is listed on another indexer, that indexer holds its own record and may produce a populated NZB, and the difference in outcome confirms the diagnosis directly.

Two lookalikes are worth separating. A malformed NZB fails at parse time with a visible error message, so the client never accepts the job. A zero-byte output after a real download means segments were listed and fetched but the assembled file has no content, which points at the post or the unpack step. The empty NZB sits between them: accepted, instant, and silent.