Recursos

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

  • NNTP com pipeline em velocidade de linha: 8,31 Gbps medidos em 10 GbE.
  • 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 +12% a +270% sobre a busca serial, e cerca de 8 conexões por servidor bastam para saturar a linha.
  • 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 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: quando fica ocioso, o daemon devolve a memória liberada ao SO, caindo para cerca de 8 MB entre trabalhos no macOS.

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 em modo armazenamento (a maioria dos lançamentos scene) são mapeadas e extraídas enquanto baixam, 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.
  • 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 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.
  • Recurso para comprimidos e criptografados: publicações fora do modo armazenamento se materializam e são extraídas pelo motor RAR nativo, tudo do RAR4 ao novo RAR7, sobrepostas ao resto da fila. Conjuntos criptografados ficam estacionados 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 conduz dez cenários de falha de ponta a ponta (430s, corrupção, truncamento, travamentos, servidores mortos, kill −9) em cada execução dos testes.
  • 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. nzb360, LunaSea e outros controles remotos do NZBGet se conectam sem modificação.
  • 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.
  • Pasta monitorada. Solte um .nzb dentro e ele baixa; o arquivo some assim que é recolhido.
  • 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.
  • 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".
  • 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.
  • Diagnóstico embutido: um visualizador de log na própria interface, 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