Do NZB a um arquivo verificado
antes de os outros terminarem de baixar.

O nzbfast é um baixador da Usenet construído em torno de uma única passagem: cada byte é decodificado, verificado e extraído enquanto baixa. Não há passagem de montagem depois, nada sobra para verificar ou extrair quando termina. No instante em que a barra de progresso enche, o arquivo está pronto e comprovadamente intacto.

8,31 Gbps em uma linha de 10 GbE 190 GB → 4m33s até um arquivo verificado Volumes RAR nunca tocam o disco Metade do disco que os concorrentes precisam RAM orçada · 0 swaps, nunca
Baixar Ver os números

macOS · Windows · Linux · Docker: um executável autossuficiente, com ferramentas de reparo e extração embutidas.

Painel do nzbfast em meio a um download a 61 MB/s: vazão com pico de 104 MB/s ao longo de um gráfico de histórico completo, gráficos ao vivo de recursos e por provedor, e as etapas do pipeline de download/verificação/extração se sobrepondo

Por que é rápido

Três ideias que os clientes convencionais não exploram por completo

Isto é arquitetura, não micro-otimização, e cada detalhe é medido em nosso benchmark log com comandos que você mesmo pode reexecutar.

🔁

NNTP com pipeline

Várias solicitações de artigos ficam em trânsito em cada conexão, então uma ida e volta nunca deixa o socket ocioso e o TCP nunca deixa sua janela de congestionamento degradar entre artigos. Em quatro locais, medimos de +12% a +270% sobre o serial, e uma linha satura com 8 conexões em vez de 30–50.

🚿

O pipeline de passagem única

Os artigos são decodificados por SIMD no próprio lugar e escritos uma única vez, direto para seus deslocamentos finais, e então verificados por PAR2 a partir dos mesmos buffers de decodificação. Nas publicações RAR em modo armazenamento, o conteúdo é extraído durante o download, então os volumes nunca existem como arquivos: o disco escrito fica em conteúdo × 1,0.

🕸️

Disponibilidade por união

Um artigo só conta como "ausente" quando todo backbone configurado o recusou. A contabilidade exata por bloco declara o trabalho COMPLETE, REPAIRABLE ou IMPOSSIBLE antes de desperdiçar bytes, puxa apenas o mínimo sob medida de blocos de recuperação e descarta downloads sem esperança em segundos.

O pipeline

Toque em cada byte uma só vez

Os concorrentes escrevem os volumes de arquivo, os leem de volta para verificar, os leem de novo para extrair e então escrevem a saída, cerca de 2× escritas e 2× leituras. O nzbfast faz assim:

socket ──TLS──▶ decodificação SIMD rapidyenc (no lugar - 4,95 GB/s por núcleo)
                   │
                   ├─▶ pwrite no deslocamento final     (posts simples)
                   │      └─ ou: tradução RAR-map ─▶ pwrite direto no
                   │         arquivo extraído (posts em modo store - os
                   │         volumes rar nunca tocam o disco)
                   ├─▶ hasher de blocos PAR2 - cada bloco verificado em MD5 do
                   │      buffer de decodificação; a verificação termina com o download
                   └─▶ registro de disponibilidade - saúde exata por bloco, ao vivo
Publicação danificada? Os blocos defeituosos são conhecidos no instante em que seus artigos falham, o mínimo sob medida de volumes de recuperação é buscado durante o download (22 blocos buscados para 20 necessários, na rodada de bench), e o reparo toca apenas os trechos danificados. Publicação impossível? Aborta em segundos tendo baixado quase nada, antes de sua cota perceber.

Recursos de destaque

Tudo o que um setup sério precisa

A lista completa (cada ajuste, cada integração) está na página de recursos.

  • Downloads em velocidade de linha: NNTP com pipeline medido a 8,31 Gbps em 10 GbE; o cliente mais rápido em cada leg limpo de benchmark, em todos os tamanhos.
  • Pipeline de passagem única: decodificação, verificação e extração se sobrepõem; volumes RAR em modo armazenamento nunca chegam ao disco; arquivos aninhados são desempacotados na mesma passagem; precisa de 1× de disco onde outros precisam de ~2×.
  • Disponibilidade por união multiprovedor: roteamento exato por bloco entre backbones; vereditos de preflight; reparo sob medida; aborto antecipado de publicações impossíveis.
  • Orçamento de memória: um orçamento de RAM global com níveis graduais de spill. Ele nunca faz swap da sua máquina: um trabalho de 190 GB termina dentro de um orçamento de 1 GB (~1,1 GB de pico de RSS).
  • Retomada à prova de travamento: um diário no nível de artigo faz com que um travamento ou kill −9 no meio do download custe quase nada: ele retoma, rebuscando apenas o que não foi salvo.
  • APIs de encaixe direto: API compatível com o SABnzbd e JSON-RPC do NZBGet: Sonarr, Radarr, nzb360 e LunaSea funcionam sem modificação. Importação de um clique da sua configuração SAB/NZBGet.
  • Indexador integrado: varre seus newsgroups para um índice local pesquisável, serve Newznab para que sua pilha *arr também possa pesquisá-lo.
  • Mural de pôsteres com metadados sem chave: imagens, notas, elenco e sinopses para tudo no seu índice, sem nenhuma chave de API para cadastrar.
  • Automação de lista de acompanhamento: nomeie uma série ou filme (estreado ou não); é capturado no momento em que aparece, depois tem a qualidade melhorada até atingir seu alvo.
  • Um único executável: reparo (par2) e extração (RAR) viajam dentro do binário. Descompacte, execute, pronto.

Benchmarks

190,6 GB → um arquivo verificado de 167,9 GB

Mesma máquina, mesmos seis provedores, execuções intercaladas uma logo após a outra. O que é cronometrado é o momento em que existe um arquivo utilizável e extraído, a única métrica que realmente importa. Cada concorrente foi ajustado ao próprio melhor documentado, a ponto de ligar o pipeline do SABnzbd, que vem sem ele.

nzbfast4m 33s
NZBGet 26.27m 58s · +75%
SABnzbd 5.0.419m 32s · +329%
rustnzb 1.3.4nenhum arquivo utilizável

NZB de 190,6 GB → um único mkv de 167,9 GB, M1 Ultra em 10 GbE, 6 provedores × 8 conexões. O mesmo trabalho também termina dentro de um orçamento de memória de 1 GB. Tabelas completas, todos os sete cenários e os legs que não vencemos (além de como reproduzi-los) estão na página de benchmarks.

Encaixa no seu setup

Aponte suas ferramentas existentes para ele

Sonarr / Radarr

Ele traz a API completa compatível com o SABnzbd, então você adiciona o nzbfast como cliente de download "SABnzbd" e ele simplesmente funciona: capturas, categorias, prioridades, repetições, scripts de pós-processamento no contrato SAB_*, histórico. A fachada Newznab vai além e deixa os *arr pesquisarem seu índice local como se fosse um indexador.

nzb360 / LunaSea

O daemon também fala o JSON-RPC do NZBGet, os populares controles remotos de celular pilotam o nzbfast sem modificação. E o próprio painel tem um layout de celular de primeira classe para quando você está longe da tela grande.

Vindo do SAB ou do NZBGet?

Um clique importa seus servidores de uma instalação existente do SABnzbd ou do NZBGet (também lê sabnzbd.ini diretamente). Pastas monitoradas, feeds RSS com filtros, pastas inteligentes com arquivamento de TV e regras de limpeza vêm junto na viagem.

Experimente nos próximos dois minutos

Descompacte, dê duplo clique no lançador, responda três perguntas (ou deixe-o encontrar sua configuração existente do SABnzbd) e o painel abre. Seu primeiro download chega em menos de dois minutos.

Baixar o nzbfast Ler a lista completa de recursos