Fonctionnalités

La version courte en haut, tout le détail en dessous.

  • NNTP pipeliné à la vitesse de la ligne: 8.31 Gbps mesurés sur 10 GbE.
  • Pipeline en une passe: décodage, vérification et extraction se chevauchent ; les volumes RAR ne touchent jamais le disque ; les archives imbriquées se décompressent dans la même passe.
  • Disponibilité en union multi-fournisseurs: complétez depuis l’union de vos serveurs, ou abandonnez tôt.
  • Budget mémoire: RAM bornée, débordement en douceur, jamais de swap.
  • Reprise résistante aux crashs: journal au niveau de l’article ; tuez le processus (kill −9) en pleine tâche et il reprend là où il s’était arrêté.
  • API compatible SABnzbd + JSON-RPC NZBGet: Sonarr/Radarr/nzb360/LunaSea fonctionnent sans modification.
  • Indexeur intégré: scannez vos groupes vers un index local, cherchable, servi en Newznab.
  • Mur d’affiches: affiches, notes, casting, grilles d’épisodes ; aucune clé API.
  • Liste de suivi + montées en qualité: récupère dès la première apparition, améliore jusqu’à la qualité cible.
  • Un seul exécutable autonome: par2 + extraction RAR embarqués.

Moteur & vitesse

  • NNTP pipeliné. Garder plusieurs requêtes en vol sur chaque connexion vainc à la fois la latence aller-retour et l’affaissement de la fenêtre de congestion TCP. Nous mesurons de +12% à +270% par rapport au mode sériel, et environ 8 connexions par serveur suffisent à saturer la ligne.
  • Décodage yEnc SIMD (rapidyenc, avec noyaux NEON et AVX) tourne à 4.95 GB/s par cœur, décodé sur place à mesure que les octets arrivent dans le chemin de réception.
  • File partagée multi-serveurs. Les fournisseurs s’équilibrent d’eux-mêmes à ~2% près, sans le moindre réglage. Le débit réel de chacun est suivi, et la fin d’une tâche est dispatchée en double pour qu’un seul serveur lent ne puisse pas faire traîner l’arrivée.
  • Enchaînement des tâches. La fin de la tâche N recouvre le début de la tâche N+1, si bien que la ligne reste allumée d’un bout à l’autre de la file : 2% d’inactivité ici contre 61% de temps mort pour SABnzbd dans le même benchmark.
  • Chien de garde anti-lenteur. Un téléchargement qui rampe sur un serveur lent pendant que les autres attendent est renvoyé en fin de file, sa progression conservée, et reprend une fois la file dégagée.
  • Préchargement sur serveur inactif : un serveur que la tâche active ne peut pas utiliser, parce que ses articles n’y sont pas stockés, démarre la tâche suivante au lieu de rester inoccupé.
  • Réglage des connexions par paliers. Plutôt que de deviner, il mesure là où le débit de chaque fournisseur cesse réellement de grimper (connexions demandées face aux connexions accordées) et s’y arrête.
  • Régulateur de vitesse automatique : un régulateur RTT optionnel, façon LEDBAT, qui cède la place au reste du trafic de votre foyer et prend ce qui reste de la ligne.
  • Limites de vitesse et planificateur hebdomadaire : des plafonds ajustables à chaud, un planning en heure locale (à l’épreuve des changements d’heure) et un « pause pendant N minutes » qui reprend tout seul.
  • Budget mémoire. Un budget de RAM global (auto : un quart de la RAM, plafonné, modifiable). Quand il se resserre, les tampons rétrécissent d’abord, puis les données débordent sur le disque et sont relues une fois la tâche apaisée. Jamais de swap. Une tâche de 190 GB se termine dans un budget de 1 GB à ~1.1 GB de RSS au pic, et un profil 2 GB mesuré et documenté existe pour les NAS.
  • Contre-pression. Un disque lent freine les sockets au lieu de laisser la RAM se remplir. Il se tient à ±1% d’un plafond d’écriture, et la RAM baisse même sous la pression.
  • Mémoire rendue après la tâche : une fois au repos, le daemon restitue la mémoire libérée à l’OS et retombe autour de 8 MB entre deux tâches sur macOS.

Le pipeline en une passe

  • Écrit une seule fois. Les articles décodés sont écrits (pwrite) droit à leur position finale dans le fichier. Aucun fichier temporaire, aucune passe d’assemblage séparée.
  • Vérification PAR2 au fil de l’eau. Chaque bloc est haché en MD5 depuis les tampons de décodage dès son arrivée : la vérification s’achève au moment même où le téléchargement se termine. C’est mieux que le quick-check dont se contentent les autres clients, et ça ne coûte rien.
  • Extraction directe : les posts RAR en mode store (la plupart des releases scene) sont cartographiés et extraits pendant leur téléchargement, si bien que les volumes n’atterrissent jamais sur le disque. Le disque écrit revient à contenu × 1.0 et l’espace requis à 1×, là où les autres en réclament environ 2×.
  • Archives imbriquées, et la profondeur ne coûte presque rien. Les archives dans des archives - RAR dans RAR, 7z dans un RAR, des empilements de nombreux niveaux - sont désimbriquées au fil des octets, à l’intérieur de la passe que nous faisions déjà. Toute la différence est là : un client qui écrit chaque couche sur le disque, la referme, la rouvre et la relit paie une passe complète par niveau, si bien que chaque couche supplémentaire lui coûte un aller-retour de plus sur le disque. Les nôtres voyagent dans la première passe, et la charge utile sort d’un empilement de dix niveaux comme elle sort d’un seul. Une copie sur le disque là où l’approche écriture-puis-relecture en garde deux ou trois.
  • Désobfuscation. Les posts obfusqués sont renommés d’après leurs métadonnées PAR2, les noms brouillés en ROT13 sont récupérés, et le tout-venant à noms hachés est classé puis écarté.
  • Réparation au plus juste. Les blocs endommagés sont connus au fil de l’eau, donc seul l’ensemble de volumes de récupération le plus léger en octets est téléchargé (un problème de sac à dos résolu) et la réparation ne touche rien d’autre que les zones endommagées.
  • Enregistrements de récupération RAR. Quand le PAR2 est épuisé, ou n’a jamais été posté, les enregistrements de récupération embarqués dans les RAR réparent les volumes endommagés sur place.
  • Réparation à chaque profondeur. Un jeu PAR2 emballé dans une couche interne est trouvé et exécuté à son propre niveau, et un post ne contenant que du PAR2 (données supprimées, un jeu de récupération à 100% laissé sur place) est reconstruit en entier puis décompressé.
  • Repli compressé et chiffré : les posts hors mode store se matérialisent et se décompressent via le moteur RAR natif, du RAR4 jusqu’au nouveau RAR7, en recouvrement avec le reste de la file. Les jeux chiffrés se garent avec un message clair plutôt que d’échouer en silence.
  • Il part lui-même à la recherche du mot de passe. La plupart des posts chiffrés n’ont pas besoin de vous. Il essaie les métadonnées du NZB et la convention de nommage {{pw}}, l’API des *arr, puis toute courte note texte postée à côté des fichiers, et à défaut les noms de la release et des fichiers eux-mêmes. Il recommence cette recherche à chaque niveau : une chaîne qui cache le mot de passe de chaque couche dans la couche au-dessus - un mot de passe différent à chaque niveau - se déverrouille de bout en bout sans que vous tapiez quoi que ce soit. Ce qui résiste vraiment passe par le déverrouillage 🔑 du tableau de bord : il déverrouille en arrière-plan, puis range normalement.
  • Garde-fous. Les volumes sources réparés sont protégés en écriture pendant la ré-extraction, la somme de contrôle propre au fichier final est vérifiée de bout en bout (activé par défaut), et un code de sortie n’annonce « succès » que lorsque l’état final est réellement utilisable.

Fiabilité & disponibilité

  • Contrôle de disponibilité avant décollage. Des balayages STAT pipelinés dressent en quelques secondes une matrice article × serveur et classent la tâche COMPLET, RÉPARABLE ou IMPOSSIBLE avant qu’un seul octet de contenu ne soit récupéré. Un post impossible s’interrompt sans presque rien avoir tiré.
  • Routage en union. Un article n’est compté comme manquant qu’une fois que chaque serveur actif l’a refusé ; jusque-là, il est routé vers celui qui le détient. Les backbones diffèrent par leur rétention et leurs retraits, si bien que l’union complète discrètement des posts qu’aucun serveur seul ne pourrait fournir.
  • Journal résistant aux crashs. Le journal travaille à la granularité de l’article. Envoyez un kill −9 en pleine tâche et il revient, ne re-téléchargeant que ce qui n’avait pas été persisté ; la file et l’historique survivent aux redémarrages.
  • Garer et réessayer : les tâches échouées se garent dans l’historique, et un nouvel essai ne récupère que les morceaux encore manquants.
  • Testé au chaos. Un serveur NNTP simulé déroule dix scénarios d’échec de bout en bout (erreurs 430, corruption, troncature, blocages, serveurs morts, kill −9) à chaque exécution des tests.
  • Score de fiabilité des fournisseurs. Les taux de complétion par serveur sont conservés durablement et affichés sur le tableau de bord, avec une alerte sous 98%.
  • Analyseur de diversité des serveurs. Il échantillonne vos serveurs par STAT et les regroupe selon les lacunes qu’ils partagent : vous voyez quels fournisseurs « différents » sont en fait le même backbone avant de payer pour une redondance que vous n’avez pas vraiment.
  • Quotas, comptes à bloc et garde-disque : quotas quotidiens et mensuels, budgets d’octets à vie pour les comptes à bloc (exclus automatiquement une fois épuisés), pause en cas d’espace faible et historique de consommation quotidien par fournisseur.
  • Détection des doublons : dupekey et dupescore, avec une alternative retenue promue automatiquement dès qu’une récupération échoue.
  • Routage tenant compte de la rétention. Les posts plus vieux que la rétention d’un serveur le contournent entièrement, et tout ce qu’aucun serveur ne peut fournir échoue aussitôt au lieu de tourner en rond.

Automatisation & intégrations

  • API compatible SABnzbd : toute la surface que les *arr utilisent vraiment : addfile/addurl, catégories, priorités, pause/reprise par tâche, réessai, pagination, clés API à deux niveaux. Sonarr et Radarr lui parlent comme si c’était SABnzbd.
  • Façade JSON-RPC NZBGet. nzb360, LunaSea et les autres télécommandes NZBGet se connectent sans modification.
  • Serveur Newznab. Votre index local répond à t=search/tvsearch/movie, si bien que les *arr peuvent traiter vos propres scans comme un indexeur.
  • Auto-récupération RSS : le flux d'un indexeur est ce à quoi s'abonne un lecteur de news, sauf qu'il liste ce qui vient d'être posté sur Usenet. Tout ce qui correspond aux filtres se télécharge tout seul. Des flux filtrés avec un langage façon NZBGet, ajoutés et édités à chaud depuis le tableau de bord.
  • Liste de suivi. Nommez les séries et les films que vous voulez, même ceux qui ne sont pas encore diffusés. Chaque épisode est récupéré dès sa première apparition et amélioré jusqu’à atteindre votre qualité cible (disons 720p → 1080p REMUX), l’ancienne copie n’étant supprimée qu’une fois la meilleure version vérifiée. Un calendrier de diffusion montre ce qui arrive.
  • Dossier surveillé. Déposez-y un .nzb et il se télécharge ; le fichier disparaît une fois pris en charge.
  • Dossiers intelligents : des règles regex, mot-clé et taille rangent les téléchargements par catégorie dès la mise en file, avec un classement TV optionnel vers Show/Season NN/Show - S01E02.ext.
  • Règles de nettoyage : les extensions parasites sont supprimées une fois la tâche terminée.
  • Déplacement vers un NAS : après extraction et renommage, les téléchargements terminés partent vers un dossier de destination en conservant l'arborescence des catégories, et des destinations par catégorie peuvent envoyer séries et films vers des partages différents. Si le partage est inaccessible, les fichiers restent sur place.
  • Scripts de post-traitement. Ils respectent le contrat d’environnement SAB_* de SABnzbd, donc les scripts que vous avez déjà tournent tels quels.
  • Migration en un clic. Il importe les serveurs depuis un ini SABnzbd ou un conf NZBGet, et lit directement sabnzbd.ini si c’est tout ce qu’il trouve.
  • Ingestion Spotnet : vérification des signatures de spots et synthèse de NZB, intégrées d’origine.

Aperçu & bibliothèque

Tableau de bord & paramètres

Queue with a per-download detail drawer: per-file progress bars, verify blocks, per-server contribution
Tiroir de la file : barres par fichier, blocs de vérification, contribution par serveur.
Settings: server editor and live speed/scheduling controls
Chaque paramètre s’édite dans le navigateur. La plupart s’appliquent à chaud.
Phone layout of the dashboard
Une vraie disposition téléphone, le même daemon.
  • Graphiques en direct, sans la moindre bibliothèque. Tout se rafraîchit chaque seconde (une aire de débit, des aires empilées par fournisseur, une chronologie de santé des vérifications, la descente de la file vers zéro, un histogramme de vitesse) et les graphiques élargissent leur fenêtre temporelle à mesure que vous élargissez le navigateur.
  • Moniteur de ressources : processeur, RAM face au budget, écritures disque et réseau sur un seul graphique, avec une alerte d’espace faible.
  • Classement des fournisseurs. Les serveurs se re-trient selon la performance en direct, chacun affichant les octets de la session, le nombre de connexions, l’utilisation et la fiabilité.
  • Gestion de la file : glissez pour réordonner, réglez priorité et catégorie en ligne, ouvrez un tiroir par téléchargement, mettez en pause de façon optimiste, ou « pause pendant N minutes ».
  • Tout se configure dans le navigateur : serveurs (avec tests de connexion en direct), vitesse et planification, connexions/fenêtre/décodeurs, disque et quota, dossiers surveillés et scripts, filtres d’indexation, bibliothèque, RSS, et sécurité avec rotation des clés. Les réglages survivent aux redémarrages.
  • Diagnostics intégrés : une visionneuse de journal dans l’interface, un benchmark système qui trouve vos plafonds réseau, calcul et disque et vous dit quoi en faire, l’analyseur de diversité des serveurs, et le réglage des connexions par paliers.
  • Consommation de données : des barres empilées par fournisseur sur 14 jours, un historique quotidien, et des compteurs à vie pour les comptes à bloc.
  • 28 langues. Le tableau de bord est livré entièrement traduit, écritures de droite à gauche comprises ; le manuel et ce site existent en 16.
  • Confort d’usage. Glissez-déposez un .nzb n’importe où, notifications de bureau, sons de fin, assistant de premier lancement, et serve --open.

Déploiement