Recursos

A versão curta em cima, o detalhe completo embaixo.

  • NNTP com pipeline em velocidade de linha: 9,0-9,3 Gbps medidos em uma linha de 10 GbE cujo próprio teto é de 9,8.
  • Pipeline de passagem única: decodificação, verificação e extração se sobrepõem; volumes RAR nunca tocam o disco; arquivos aninhados são desempacotados na mesma passagem.
  • Disponibilidade por união multiprovedor: completa a partir da união dos seus servidores, ou aborta cedo.
  • Orçamento de memória: RAM limitada, spill gradual, nunca faz swap.
  • Retomada à prova de travamento: diário no nível de artigo; dê kill −9 no meio do trabalho e ele retoma de onde parou.
  • APIs compatível com SABnzbd + JSON-RPC do NZBGet: Sonarr/Radarr/nzb360/LunaSea funcionam sem modificação.
  • Indexador integrado: varre grupos para um índice local, pesquisável, que serve Newznab.
  • Mural de pôsteres: imagens, notas, elenco, grades de episódios; nenhuma chave de API.
  • Captura automática da lista de acompanhamento + melhorias de qualidade: captura na primeira aparição, melhora até a qualidade-alvo.
  • Executável único e autossuficiente: par2 + extração RAR embutidos.

Motor e velocidade

  • NNTP com pipeline. Manter várias solicitações em trânsito em cada conexão vence tanto a latência de ida e volta quanto a degradação da janela de congestionamento do TCP. Medimos de +64% a +270% sobre a busca serial, reproduzido em cada tempo de ida e volta, de um enlace de data center de 14 ms até 63 ms por satélite.
  • Decodificação yEnc por SIMD (rapidyenc, com kernels NEON e AVX) roda a 4,95 GB/s por núcleo, decodificando no próprio lugar à medida que os bytes chegam pelo caminho de recepção.
  • Fila compartilhada entre servidores. Os provedores se equilibram sozinhos dentro de ~2%, sem nenhum ajuste. A taxa real de cada um é acompanhada, e a cauda de um trabalho é despachada em duplicata para que um único servidor lento não arraste o final.
  • Absorção entre trabalhos. A cauda do trabalho N se sobrepõe ao início do trabalho N+1, de modo que a linha continua acesa de ponta a ponta ao longo de uma fila inteira: 2% de ociosidade aqui contra os 61% de tempo morto do SABnzbd 5.0.4 no mesmo bench.
  • Vigia de trabalhos lentos. Um download que se arrasta em um servidor lento enquanto os demais ficam parados é jogado para o fim da fila, com o progresso preservado, e recomeça assim que a fila esvazia.
  • Pré-carga em servidor ocioso: um servidor que o trabalho ativo não consegue usar, porque seus artigos não estão armazenados nele, começa o próximo trabalho da fila em vez de ficar parado.
  • Escada de ajuste de conexões. Em vez de chutar, ela mede onde a vazão de cada provedor realmente para de subir (conexões pedidas contra concedidas) e se fixa ali.
  • Regulador automático de velocidade: um regulador de RTT opcional ao estilo LEDBAT que cede lugar ao restante do tráfego da sua casa e fica com o que sobra da linha.
  • Limites de velocidade e agendador semanal: tetos ajustáveis ao vivo, uma agenda em horário local (à prova de horário de verão) e um "pausar por N minutos" que retoma sozinho.
  • Orçamento de memória. Um único orçamento global de RAM (automático: um quarto da RAM, com limite, substituível). Conforme ele aperta, primeiro os buffers encolhem, depois os dados fazem spill para o disco e voltam a ser lidos quando o trabalho estabiliza. Ele nunca faz swap. Um trabalho de 190 GB termina dentro de um orçamento de 1 GB com ~1,1 GB de pico de RSS, e há um perfil de 2 GB, medido e documentado, para NAS.
  • Contrapressão. Um disco lento estrangula os sockets em vez de deixar a RAM encher. Ele se mantém dentro de ±1% de um teto de escrita, e a RAM na verdade cai sob pressão.
  • Corte de memória após o trabalho: assim que um trabalho termina e o daemon fica ocioso, os buffers e caches que ele havia levantado voltam ao SO em vez de ficarem guardados para o próximo.

O pipeline de passagem única

  • Escreva uma vez. Os artigos decodificados vão de pwrite direto para seus deslocamentos finais no arquivo. Sem arquivos temporários, sem uma passagem de montagem à parte.
  • Verificação PAR2 no fluxo. Cada bloco tem o MD5 calculado a partir dos buffers de decodificação assim que chega, então a verificação termina no exato momento em que o download termina. Isso supera a verificação rápida com que os outros clientes se contentam, e não custa nada.
  • Extração direta: publicações RAR, 7z e zip são mapeadas e extraídas enquanto baixam, tanto em modo armazenamento quanto comprimidas, de modo que os volumes nunca chegam ao disco. O disco escrito fica em conteúdo × 1,0 e o disco necessário em 1×, ao passo que os outros querem cerca de 2×.
  • Arquivos aninhados, e a profundidade quase não custa nada. Arquivos dentro de arquivos - RAR em RAR, 7z dentro de um RAR, escadas de muitos níveis - são desaninhados conforme os bytes chegam, dentro da passagem que já estávamos fazendo. É aí que está toda a diferença: um cliente que grava cada camada em disco, fecha, reabre e relê paga uma passagem inteira por nível, então cada camada que desce lhe custa mais uma ida e volta ao disco. As nossas pegam carona na primeira passagem, e o payload sai de uma escada de dez níveis do mesmo jeito que sai de uma de um nível. Uma cópia em disco onde gravar-e-reler segura duas ou três.
  • Desofuscação. Publicações ofuscadas são renomeadas a partir de seus metadados PAR2, nomes embaralhados por ROT13 são resgatados, e o lixo com nome de hash é classificado e barrado.
  • Arquivos simplesmente divididos. Conjuntos divididos ao estilo HJSplit, em partes .001/.002 ou .1/.2 sem cabeçalho de arquivo nenhum, são reconhecidos e recompostos no arquivo original em vez de acabarem soltos no seu disco.
  • Reparo sob medida. Os blocos danificados são conhecidos no momento em que acontecem, então só o conjunto de volumes de recuperação com menor número de bytes é buscado (um problema da mochila resolvido) e o reparo não toca em nada além dos trechos danificados.
  • Registros de recuperação do RAR. Quando o PAR2 se esgota, ou nunca foi publicado, os registros de recuperação embutidos no RAR e os volumes de recuperação .rev separados reparam os volumes danificados no próprio lugar.
  • Reparo em todas as profundidades. Um conjunto PAR2 embalado dentro de uma camada interna é encontrado e executado no seu próprio nível, e uma publicação só com par (dados apagados, um conjunto de recuperação de 100% deixado para trás) é reconstruída por inteiro e depois desempacotada.
  • Comprimidos e criptografados, na mesma passagem: conjuntos comprimidos são decodificados pelo motor RAR nativo à medida que os volumes chegam, tudo do RAR 1.5 ao novo RAR7, e os criptografados são destravados na escrita assim que você fornece a senha - inclusive as cadeias em que a senha de cada camada vem empacotada na camada acima. Um conjunto sem senha fica estacionado com uma mensagem clara em vez de falhar em silêncio.
  • Ele mesmo vai atrás da senha. A maioria dos posts criptografados não precisa de você. Ele tenta os metadados do próprio NZB e a convenção de nome {{pw}}, a API dos *arr, depois qualquer nota de texto curta postada junto aos arquivos e, na falta disso, os nomes da release e dos próprios arquivos. Repete essa busca em cada nível: uma corrente que esconde a senha de cada camada dentro da camada acima - uma senha diferente em cada nível - se abre até o fim sem você digitar nada. O que realmente sobra passa pelo desbloqueio 🔑 no painel: desbloqueia em segundo plano e depois arquiva normalmente.
  • Trilhos de segurança. Os volumes de origem reparados ficam protegidos contra escrita enquanto a reextração roda, o checksum do próprio arquivo final é verificado de ponta a ponta (ligado por padrão), e o código de saída só informa "sucesso" quando o estado final é de fato utilizável.

Confiabilidade e disponibilidade

  • Verificação de disponibilidade pré-voo. Varreduras STAT com pipeline montam uma matriz por artigo × por servidor em segundos e marcam o trabalho como COMPLETE, REPAIRABLE ou IMPOSSIBLE antes de baixar um único byte de conteúdo. Uma publicação impossível aborta tendo puxado quase nada.
  • Roteamento por união. Um artigo só conta como ausente depois que todos os servidores ativos o recusaram; até lá, ele é roteado para qualquer servidor que o tenha. Os backbones diferem em retenção e remoções, então a união conclui discretamente publicações que nenhum servidor sozinho conseguiria.
  • Diário à prova de travamento. O diário trabalha na granularidade de artigo. Dê um kill −9 no meio do trabalho e ele volta, rebuscando só o que ainda não tinha sido persistido; a fila e o histórico sobrevivem a reinícios.
  • Estacionar e repetir: trabalhos que falham ficam estacionados no histórico, e uma nova tentativa puxa apenas as partes que ainda faltam.
  • Testado no caos. Um servidor NNTP simulado interpreta 33 perfis de falha, e oito percursos de ponta a ponta rodam em cada execução dos testes: uma referência limpa mais conexões caídas, silêncio total, quedas de tensão, corrupção, enlaces estrangulados, truncamento de TLS e kill −9.
  • Pontuação de confiabilidade de provedor. As taxas de conclusão de cada servidor são guardadas para sempre e mostradas no painel, com um aviso abaixo de 98%.
  • Analisador de diversidade de servidores. Ele faz amostragem por STAT nos seus servidores e os agrupa pelas lacunas que compartilham, para você saber quais provedores "diferentes" são na verdade o mesmo backbone antes de pagar por uma redundância que você não tem de fato.
  • Cotas, contas de bloco e guarda de disco: cotas diárias e mensais, orçamentos de bytes vitalícios para contas de bloco (excluídas automaticamente quando se esgotam), uma pausa por pouco espaço em disco e histórico de uso diário por provedor.
  • Detecção de duplicados: dupekey e dupescore, com uma alternativa reservada promovida automaticamente no instante em que uma captura falha.
  • Roteamento consciente de retenção. Publicações mais antigas que a retenção de um servidor o ignoram por completo, e o que nenhum servidor consegue servir falha de imediato em vez de ficar girando.

Automação e integrações

  • API compatível com o SABnzbd: toda a superfície que os *arr realmente usam: addfile/addurl, categorias, prioridades, pausar/retomar por trabalho, repetir, paginação, chaves de API em dois níveis. O Sonarr e o Radarr conversam com ele como se fosse o SABnzbd.
  • Fachada JSON-RPC do NZBGet. LunaSea e outros controles remotos do NZBGet se conectam sem modificação. (nzb360: SABnzbd API)
  • Servidor Newznab. Seu índice local responde a t=search/tvsearch/movie, então os *arr podem tratar suas próprias varreduras como um indexador.
  • Captura automática por RSS: o feed de um indexador é a mesma coisa que um leitor de notícias assina, só que lista o que acabou de ser publicado na Usenet. Tudo o que corresponde aos filtros baixa sozinho. Feeds filtrados com uma linguagem ao estilo NZBGet, adicionados e editados ao vivo pelo painel.
  • Lista de acompanhamento. Nomeie as séries e os filmes que você quer, até os que ainda nem estrearam. Cada episódio é capturado na primeira aparição e melhorado até chegar à qualidade-alvo (digamos, 720p → 1080p REMUX), e a cópia substituída só é apagada depois que a melhoria é verificada. Um calendário de estreias mostra o que está por vir. Ela também pode seguir sua lista de acompanhamento do Plex: vincule sua conta, ou cole o endereço da lista, e tudo o que você adicionar lá também é acompanhado aqui.
  • Avisos onde você já olha. E-mail, Discord, Slack, Telegram, Pushover, ntfy, Gotify e qualquer servidor Apprise que você mantenha, além das atualizações de biblioteca do Kodi, Plex e Jellyfin e de um webhook cujo modelo você mesmo escreve.
  • Pasta monitorada. Solte um .nzb dentro e ele baixa; o arquivo some assim que é recolhido. As subpastas também são monitoradas, e um arquivo solto em watch/tv chega na categoria tv.
  • Pastas inteligentes: regras de regex, palavra-chave e tamanho organizam os downloads em categorias já no enfileiramento, com arquivamento de TV opcional para Show/Season NN/Show - S01E02.ext.
  • Comportamento por categoria. Cada categoria carrega sua própria pasta de destino, sua prioridade e seu script de pós-processamento, de modo que séries e filmes podem cair em lugares diferentes sob regras diferentes.
  • Regras de limpeza: extensões de lixo são removidas assim que um trabalho conclui.
  • Mover para um NAS: após desempacotar e renomear, os downloads concluídos vão para uma pasta de destino mantendo a estrutura de categorias, e os destinos por categoria podem mandar séries e filmes para compartilhamentos diferentes. Se o compartilhamento estiver inacessível, os arquivos ficam onde estão.
  • Scripts de pós-processamento. Eles respeitam o contrato de ambiente SAB_* do SABnzbd, então os scripts que você já tem rodam do jeito que estão.
  • Migração de um clique. Ele importa servidores de um ini do SABnzbd ou de um conf do NZBGet, e lê o sabnzbd.ini diretamente se for só isso que encontrar.
  • Ingestão de Spotnet: verificação de assinatura de spot e síntese de NZB, embutidas de fábrica.

Prévia e biblioteca

Painel e ajustes

Fila com uma gaveta de detalhes por download: barras de progresso por arquivo, blocos de verificação, contribuição por servidor
Gaveta da fila: barras por arquivo, blocos de verificação, contribuição por servidor.
Ajustes: editor de servidor e controles ao vivo de velocidade/agendamento
Cada ajuste editável no navegador. A maioria se aplica ao vivo.
Layout de celular do painel
Layout de celular de verdade, o mesmo daemon.
  • Gráficos ao vivo, sem bibliotecas. Tudo é atualizado uma vez por segundo (uma área de vazão, uma área empilhada por provedor, uma linha do tempo de saúde da verificação, a queima da fila, um histograma de velocidade) e os gráficos alargam sua janela de tempo conforme você alarga o navegador.
  • Monitor de recursos: CPU, RAM contra o orçamento, escritas em disco e rede em um único gráfico, com um aviso de pouco espaço em disco.
  • Ranking de provedores. Os servidores se reordenam sozinhos pelo desempenho ao vivo, cada um mostrando bytes da sessão, número de conexões, utilização e confiabilidade.
  • Gerenciamento da fila: arraste para reordenar, defina prioridade e categoria na própria linha, abra uma gaveta por download, pause de forma otimista ou "pause por N minutos". Selecione várias linhas de uma vez, na fila ou no histórico, e trate todas juntas - com o mouse ou pelo teclado.
  • Um histórico que guarda tudo. Os trabalhos concluídos vão para o próprio armazenamento deles, sem limite de linhas, paginado e pesquisável, e sobrevivem a reinicializações. Limites por idade e por quantidade existem se você quiser, e estão desligados.
  • Tudo configurável no navegador: servidores (com testes de conexão ao vivo), velocidade e agenda, conexões/janela/decodificadores, disco e cota, pastas monitoradas e scripts, filtros de indexação, biblioteca, RSS e segurança com rotação de chave. Os ajustes sobrevivem a reinícios.
  • HTTPS embutido. Aponte-o para um certificado e uma chave e o único listener responde https em vez de http, tanto o painel quanto a API. Um certificado quebrado ou vencido se recusa a iniciar e nomeia o arquivo, em vez de aparecer mais tarde como erro de navegador em outro lugar.
  • Diagnóstico embutido: um visualizador de log na própria interface que você pode filtrar por etiqueta e exportar, uma resposta por download para "por que isto está lento?" que nomeia a etapa que limita, um benchmark do sistema que descobre os tetos de rede, cálculo e disco e diz o que fazer a respeito, o analisador de diversidade de servidores e a escada de conexões.
  • Uso de dados: barras empilhadas por provedor de 14 dias, histórico diário e contadores vitalícios para contas de bloco.
  • 28 idiomas. O painel vem totalmente localizado, incluindo escritas da direita para a esquerda; o manual e este site estão em 16.
  • Qualidade de vida. Arraste e solte um .nzb em qualquer lugar, notificações da área de trabalho, sons de conclusão, um assistente de primeira execução e serve --open.

Implantação