🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Cette page s'adresse à vous si vous voulez plafonner le nombre de torrents actifs en même temps, arrêter ou retirer des seeds après un ratio ou une durée de seed, ou limiter les débits d'envoi et de réception. Vous y verrez quelle clé fait quoi, où la régler (interface web, API native, API qBittorrent), sa valeur par défaut exacte pour race et hoard, et ce qui manque encore en 4.4. Termes : Concepts & glossaire. Moteurs et rôles : Moteurs : race & hoard.

Chaque réglage de cette page est par moteur : [race], [hoard], ou la session d'un bloc de moteur supplémentaire (un moteur supplémentaire hérite des valeurs de son rôle sauf si sa propre session les définit). Sauf start_paused, chaque clé ici est appliquée à chaud quand vous la modifiez depuis l'interface web ou une API : enregistrez-la et le passage suivant du worker l'utilise, sans redémarrage. Une modification à la main de default.toml ne l'est pas : elle est lue au démarrage suivant, ou quand la prochaine modification par l'interface ou une API réécrit le fichier (Config : moteurs & drain race).

L'éditeur de réglages liste queueing, active_seeds, active_limit, les clés des torrents lents, des limites de partage et des plafonds de débit, ainsi que choking, même quand votre default.toml ne les contient pas, à leur valeur par défaut ; en enregistrer une la crée dans [race] ou [hoard]. active_downloads et max_uploads_per_torrent n'apparaissent que si le fichier les contient déjà (le modèle livré n'a active_downloads que dans [hoard]). L'éditeur ne couvre que [race] et [hoard] : pour un moteur supplémentaire, utilisez les routes natives (elles écrivent dans son bloc) ou modifiez le fichier.

Chaque moteur local fait tourner un gestionnaire de file. Son premier passage a lieu environ une minute après le démarrage du moteur (30 secondes de stabilisation, puis l'attente de 30 secondes), puis un passage toutes les 30 secondes, qui relit les limites dans la configuration en cours à chaque fois.

0 ou une valeur négative signifie « aucun plafond » pour les trois. queueing existe comme garde-fou : la 3.x mettait active_seeds = 50 / active_limit = 100 sur race, et un fichier qui les porte arrêterait sinon tous les seeds sauf 50 lors de la mise à jour. Ces deux clés ne font rien tant que vous ne réglez pas queueing = true.

• Un torrent que vous avez arrêté (Arrêter (Stop), l'arrêt d'une limite de partage) est invisible pour la file : il ne prend pas d'emplacement et n'est pas démarré.
• Un torrent en erreur est laissé de côté. Un torrent en cours de vérification occupe un emplacement de téléchargement.
• Les téléchargements sont classés selon le nombre de seeders de l'essaim, tiré du cache d'annonces des trackers, le plus de seeders en premier : celui qui a le plus de chances de finir obtient l'emplacement. Sous le plafond, un téléchargement en attente est démarré ; au-delà, un téléchargement actif est arrêté. Il garde sa progression et affiche en file (queued) (infobulle En attente d'un créneau (Waiting for a slot) ; queuedDL via le shim) jusqu'à ce qu'un emplacement se libère.
• Le nombre de seeders est le dernier qu'un tracker a donné en réponse à une annonce. Un torrent en file est arrêté, donc il n'annonce pas et son nombre reste celui qu'il avait quand il a été arrêté ; un torrent qui n'a jamais annoncé compte 0. Les chiffres de scrape ne servent pas au classement. Une release morte se classe donc en dernier et attend que moins de torrents au-dessus d'elle aient besoin d'un emplacement ; sans la règle des torrents lents ci-dessous, elle peut attendre tant que des téléchargements mieux seedés continuent d'arriver.
• Les seeds (seulement sous queueing) sont gardés par ancienneté, le plus ancien ajout d'abord. Leur plafond est active_seeds, et au plus active_limit moins les téléchargements actifs à ce moment. Un seed au-delà est arrêté et noté comme mis de côté (parked) (queuedUP via le shim). La file ne redémarre que les seeds qu'elle a elle-même mis de côté ; levez le plafond et chaque seed mis de côté redémarre.
• Classer par ancienneté plutôt que par un chiffre de l'essaim est délibéré : un classement qui bouge arrêterait et démarrerait des seeds à chaque passage, et chaque arrêt envoie une annonce stopped.

flowchart TD
    P["Passage de file, toutes les 30 s, config en cours"] --> L{"Un plafond ?<br/>active_downloads > 0, ou queueing<br/>avec active_seeds / active_limit > 0"}
    L -->|non| N["Rien n'est touché<br/>(les seeds mis de côté avant redémarrent)"]
    L -->|oui| F["Écartés : torrents que vous avez arrêtés, torrents en erreur"]
    F --> D["Torrents incomplets (vérification comprise),<br/>le plus de seeders de l'essaim d'abord"]
    D --> S1{"dont_count_slow_torrents et celui-ci tourne<br/>sous son seuil pendant la minuterie ?"}
    S1 -->|oui| K1["Continue de tourner, n'occupe pas d'emplacement"]
    S1 -->|non| C1{"Sous min(active_downloads, active_limit) ?"}
    C1 -->|oui| R1["Tourne : démarré s'il attendait"]
    C1 -->|non| Q1["Arrêté s'il tournait : en file"]
    R1 --> SE
    Q1 --> SE
    K1 --> SE
    SE{"queueing avec active_seeds<br/>ou active_limit ?"} -->|non| E["Fin du passage"]
    SE -->|oui| D2["Seeds actifs ou mis de côté, le plus ancien ajout d'abord"]
    D2 --> S2{"Règle des lents : envoie sous<br/>son seuil pendant la minuterie ?"}
    S2 -->|oui| K2["Continue de tourner, n'occupe pas d'emplacement"]
    S2 -->|non| C2{"Sous min(active_seeds,<br/>active_limit moins les téléchargements actifs) ?"}
    C2 -->|oui| R2["Tourne : un seed mis de côté est démarré"]
    C2 -->|non| Q2["Arrêté et mis de côté : en file"]

L'option « ne pas compter les torrents lents dans ces limites » de qBittorrent. Un torrent actif qui reste sous son seuil pendant la durée de la minuterie continue de tourner mais ne compte plus dans active_downloads, active_seeds ni active_limit, si bien que le candidat suivant obtient l'emplacement. Cela fonctionne avec ou sans queueing (pour active_downloads).

Ces quatre clés ne sont pas dans le modèle livré ; l'éditeur de réglages les affiche aux valeurs ci-dessus (l'interrupteur comme bascule, les trois chiffres comme champs numériques ; puis Enregistrer les réglages). Avec la règle activée, le plafond limite les torrents rapides, pas les torrents actifs : une release bloquée à 99 % en attente d'un seeder cesse d'occuper l'un de vos emplacements, et plus de torrents que le plafond peuvent tourner en même temps.

• Seul un téléchargement actif peut devenir lent, et un téléchargement au point mort (stalledDL : actif, aucune donnée n'arrive) est actif : après la minuterie, il libère son emplacement. Un torrent en file n'est pas actif, donc la règle ne s'applique jamais à lui ; il obtient un emplacement uniquement par son rang de seeders.
• La minuterie repart à zéro chaque fois que le débit du torrent atteint le seuil. Un torrent lent qui accélère compte de nouveau au passage suivant, à sa place dans le classement par seeders : sous le plafond, il continue de tourner, et le téléchargement actif le moins bien classé au-delà du plafond est arrêté (en file) ; hors du plafond, c'est lui qui est arrêté et mis en file.

• Forcer le téléchargement (Force download) / Ne plus forcer (Stop forcing) (clic droit › État (State), affiché pour les torrents hoard incomplets) marque le torrent comme forcé : il apparaît sous la puce de filtre Forced de la liste Hoard. La file fait tourner un torrent forcé au-delà du plafond sans le compter dans les emplacements : un torrent forcé en file est démarré au passage suivant (dans les 30 s) et n'est jamais arrêté par la file. Un torrent que vous avez arrêté vous-même reste arrêté jusqu'à ce que vous le Démarriez (Start).
• Démarrer (Start) sur un torrent en file non forcé le démarre, mais le passage suivant (dans les 30 s) l'arrête de nouveau s'il ne se classe pas sous le plafond. Forcer le téléchargement est le moyen de doubler la file.
• Via le shim, torrents/setForceStart avec value=true fait ce que fait Forcer le téléchargement, sur chaque copie du torrent, et le démarre, y compris un torrent arrêté : il tourne au-delà du plafond de n'importe quel moteur. value=false retire la marque et rend le torrent à la file. Les lignes indiquent toujours force_start: false.
• torrents/topPrio, bottomPrio, increasePrio, decreasePrio répondent 409 : Torrent queueing is not enabled quand aucun moteur qui détient les torrents n'a de file, Hydranos orders its queue itself (most seeders first for downloads, oldest first for seeds): positions cannot be set; force start runs a torrent past it quand l'un d'eux en a une.

[race]
active_downloads = 5                 # à chaud si enregistré depuis l'UI ou une API ; `queueing` inutile
dont_count_slow_torrents = true      # une release au point mort libère son emplacement
slow_torrent_dl_rate_threshold = 2   # Kio/s
slow_torrent_inactive_timer = 60     # secondes

À quoi vous attendre :

• Vous venez de qBittorrent derrière Sonarr/Radarr ? Vos torrents importés et leurs grabs sont dans hoard : mettez plutôt ces clés sous [hoard] (le modèle y a déjà active_downloads, donc Session Hoard l'affiche). Voir Migrer depuis qBittorrent.
• Race n'a pas de plafond de téléchargement par défaut (hoard en a 10). Réglez-le dans le fichier comme ci-dessus (l'éditeur Session Race n'affiche active_downloads qu'une fois que le fichier le contient), ou via le shim (ci-dessous). Enregistré depuis l'interface ou une API, il s'applique au passage suivant ; une modification à la main du fichier attend le démarrage suivant ou le prochain enregistrement depuis l'interface.
• Les 5 qui tournent sont les 5 qui ont le plus de seeders dans leur essaim, pas les 5 premiers ajoutés. Les autres affichent en file, avec leur progression conservée.
• Un torrent que vous avez arrêté à la main ne compte pas et n'est pas démarré.
• Avec la règle des lents, plus de 5 peuvent tourner : les lents continuent sans emplacement. Laissez-la désactivée pour un plafond strict de 5.
• queueing n'est pas nécessaire : il ne gouverne que active_seeds et active_limit.
• Via le shim, app/setPreferences avec {"max_active_downloads": 5} fait la même chose, mais écrit active_downloads sur tous les moteurs locaux, hoard compris. app/preferences affiche les valeurs de race (max_active_downloads à -1 quand race n'en a pas, les clés des torrents lents à celles de race ou à leurs valeurs par défaut), et setPreferences n'écrit max_active_downloads et chaque clé des torrents lents que si elle diffère de cela : un client qui renvoie la page qu'il a lue laisse vos valeurs [hoard] intactes, mais un client qui envoie une nouvelle valeur les écrase sur tous les moteurs.
• Un moteur supplémentaire prend active_downloads dans sa propre session, ou dans la section de son rôle s'il n'en définit pas.

Les limites de partage de qBittorrent : quand un seed atteint l'une quelconque de ses limites (chacune testée avec >=), l'action du moteur est appliquée.

Une valeur négative désactive une limite. "pause" et "" se lisent comme stop, de même qu'une valeur que le démon ne sait pas lire. Le ratio vaut envoyé ÷ reçu (compteurs à vie) ; quand le reçu est inférieur à 1 % des données détenues (un ajout en mode seed ou un cross-seed), il vaut envoyé ÷ données détenues, comme dans qBittorrent.

Une limite n'agit jamais avant que le seed ait servi le Minimum seed de son tracker (announce_min_seed_hours, déclaré par hôte de tracker dans l'onglet Trackers), le même test que celui du drain race (Drain race & graduation). C'est vrai pour toutes les actions, stop compris.

• Un tracker sans rien de déclaré retient la limite : le seed continue de seeder, quoi que dise la limite. Pour laisser les limites agir sur les torrents d'un tracker, déclarez ses heures, 0 compris.
• Un torrent sans tracker ne doit rien : l'action s'applique.
• Le tracker testé est le premier tracker vivant du torrent.
• Un seed retenu est journalisé une fois, pas à chaque passage : share limit reached, held: the tracker declares no minimum seeding time … ou … the tracker's minimum seeding time is not served yet.

flowchart TD
    A["Passage des limites de partage : 90 s après le démarrage,<br/>puis toutes les 120 s, par moteur local"] --> B{"En seed, ou arrêté par la file<br/>avec toutes ses données ?"}
    B -->|"non : téléchargement, vérification,<br/>erreur, arrêté par vous"| X["Non touché"]
    B -->|oui| C{"Ratio, durée de seed ou durée d'inactivité<br/>à sa limite ou au-delà (celle du torrent, sinon du moteur) ?"}
    C -->|non| X
    C -->|oui| D{"Minimum seed du tracker déclaré<br/>et servi ? (pas de tracker : oui)"}
    D -->|non| H["Retenu : continue de seeder, journalisé une fois"]
    D -->|oui| M{"Déjà 500 actions dans ce passage ?"}
    M -->|oui| NX["Laissé au passage suivant"]
    M -->|non| ACT{"share_limit_action du moteur"}
    ACT -->|stop| ST["Arrêté comme par Arrêter :<br/>affiché arrêté, la file ne le redémarre jamais"]
    ACT -->|remove| RM["Retiré de ce moteur,<br/>les trackers reçoivent stopped, les fichiers restent"]
    ACT -->|remove_with_files| RF["Retiré ; fichiers supprimés<br/>sauf ceux qu'un autre torrent lit"]

• Chaque moteur local a son propre worker ; au plus 500 arrêts ou retraits par passage, donc une limite de ratio activée sur une grosse bibliothèque étale son travail : au plus 15 000 actions par heure et par moteur, si bien que 100 000 seeds déjà au-delà de la limite mettent environ 7 heures à être traités.
• Le retrait passe par le chemin de suppression normal : les trackers reçoivent stopped, et les fichiers sont supprimés sauf ceux qu'un autre torrent chargé lit au même chemin (voir Jobs, actions groupées & déplacement).
• La durée de seed est la durée de seed comptée du torrent, conservée d'un redémarrage à l'autre.

Non implémenté en 4.4 : l'horloge d'inactivité vit en mémoire — elle démarre quand le worker voit le seed pour la première fois, donc chaque démarrage du démon accorde de nouveau un max_inactive_seeding_time complet (l'éditeur indique « Comptées depuis le démarrage du daemon » (Counted from the daemon's start)) — il n'y a pas d'action par torrent (les limites d'un torrent utilisent toujours le share_limit_action de son moteur) et pas de super seeding.

Un torrent peut porter ses propres limites : -2 = suivre son moteur, -1 = aucune limite, ≥ 0 = sa propre limite (durées en minutes). Elles appartiennent au torrent, donc chaque copie les a ; chaque copie utilise quand même l'action de son propre moteur.

• Interface web : clic droit › Limites de partage… ouvre Limites de partage: {n} torrent(s) (Share limits: {n} torrent(s)) avec Limite de ratio (Ratio limit), Limite de durée de seed (minutes) (Seeding time limit (minutes)) et Limite de seed inactif (minutes) (Inactive seeding time limit (minutes)), puis Appliquer (Apply) / Annuler (Cancel). Un champ vide garde la valeur actuelle. Pour un seul torrent, les champs partent de ses valeurs actuelles.
• Panneau de détail (race et hoard, Général (General)) : la ligne Limites de partage (Share limits) montre ce qui est en vigueur, par exemple ratio 2 · partage 1440 min · inactif aucune → arrêt (ratio 2 · seeding 1440 min · inactive none → stop), avec (engine) à côté d'une valeur reprise du moteur.
• Native : GET|POST /api/torrents/:info_hash/share-limits, corps {"ratio_limit": 2.0, "seeding_time_limit": 1440, "inactive_seeding_time_limit": -2} (chacun facultatif, au moins un, sinon 400). La réponse liste, par copie locale, les valeurs propres du torrent, les valeurs effective et l'action du moteur.
• Shim : torrents/setShareLimits avec hashes (ou all), ratioLimit et seedingTimeLimit obligatoires (400 sans eux), inactiveSeedingTimeLimit facultatif (absent = -2). Les trois mêmes champs sont lus sur torrents/add. torrents/info et properties portent ratio_limit, seeding_time_limit, inactive_seeding_time_limit (ceux du torrent) et max_ratio, max_seeding_time, max_inactive_seeding_time (en vigueur).

• Interface web : Session Race / Session Hoard, clés comme ci-dessus ; share_limit_action est une liste déroulante (stop, remove, remove_with_files).
• Native : GET|POST /api/engines/:id/share-limits, corps avec n'importe lesquels de max_ratio, max_seeding_time, max_inactive_seeding_time, share_limit_action. Champ inconnu ou action invalide → 400, moteur inconnu → 404. La route écrit la clé dans [race], [hoard] ou le bloc du moteur (en la créant si elle manque).
• Shim : app/preferences affiche les limites de race (ou du premier moteur local) : max_ratio_enabled, max_ratio, max_seeding_time_enabled, max_seeding_time, max_inactive_seeding_time_enabled, max_inactive_seeding_time, max_ratio_act (0 arrêt, 1 retrait, 3 retrait avec les fichiers). app/setPreferences ne prend une valeur qu'avec son drapeau *_enabled et l'écrit sur tous les moteurs locaux, et seulement si elle diffère de ce que la page affiche (un client qui renvoie la page entière ne change rien). max_ratio_act = 2 (super seeding) est journalisé et laisse l'action inchangée.

Une limite de partage et un workflow peuvent faire le même travail ; un workflow sert aux règles qu'une limite de partage ne sait pas exprimer (par catégorie, par tracker, tags…).

Trois niveaux, chacun facultatif. Le plafond du client est partagé par tous les moteurs, celui d'un moteur par l'ensemble des torrents de ce moteur (un plafond sur leur somme, pas une valeur par défaut par torrent), celui d'un torrent par ce seul torrent. Un bloc de données doit passer les trois, donc le plus étroit l'emporte :

• Modèle, race et hoard : upload_rate_limit = 0, download_rate_limit = 0 (illimité). 0 ou négatif = illimité à tous les niveaux.
• Les plafonds sont des seaux à jetons sur le trafic des pairs, avec une rafale d'un quart de seconde (au moins 32 Kio). Une modification s'applique aussitôt, sans redémarrage.
• Limiter le débit… ouvre Limiter le débit: {n} torrent(s) (Limit rate: {n} torrent(s)) avec Limite d'envoi (Kio/s) (Upload limit (KiB/s)) et Limite de réception (Kio/s) (Download limit (KiB/s)) : « Plafond propre à ce torrent, en Kio/s. 0 = aucun plafond propre (celui de l'engine s'applique toujours). Laissez un champ vide pour garder sa valeur actuelle. » La route native plafonne toutes les copies locales sauf si ?engine= en désigne une ; le shim plafonne toutes les copies.
• La ligne Limites de débit (Speed limits) du panneau de détail se lit ↑ X · ↓ Y : pour chaque sens, le plafond propre du torrent, ou celui du moteur suivi de (engine) quand le torrent n'en a pas ou que celui du moteur est plus étroit, ou illimité (unlimited). Le plafond du client n'y est pas affiché.
• GET /api/engines/:id/rate-limits renvoie les plafonds du moteur lus dans le fichier (upload_kib, download_kib), ce que le moteur applique en ce moment (upload_limit, download_limit, octets/s) et le plafond du client (client_upload_limit, client_download_limit).
• Via le shim, transfer/info et sync/maindata indiquent up_rate_limit / dl_rate_limit = le plafond du client ; torrents/uploadLimit / downloadLimit répondent 0 pour aucun, torrents/info indique -1.

Non implémenté en 4.4 : le plafond de tout le client ne se règle que par l'API qBittorrent — aucun contrôle de l'interface web ni aucune route native ne l'écrit — et il n'y a pas de limites de débit alternatives ni planifiées (toggleSpeedLimitsMode n'existe pas).

Désactivé par défaut, et mieux vaut le laisser ainsi. Avec choking = true, chaque torrent en seed ne sert que max_uploads_per_torrent pairs intéressés à la fois, reclassés toutes les 10 secondes selon 0.7 × rarity + 0.3 × speed (rareté = part du torrent qui manque encore au pair ; vitesse = ce qu'il a reçu dans les 10 dernières secondes, rapporté au plus rapide). Les torrents en téléchargement ne sont pas chokés. Désactivé en cours de route, il libère (unchoke) tous les pairs qu'il avait chokés.

max_uploads_per_torrent n'est lu que quand choking = true ; négatif = illimité. Les deux s'appliquent à chaud. Le modèle explique pourquoi il est désactivé : sur une grosse bibliothèque, il fait tourner les pairs et peut diviser l'envoi total par dix ; ne l'activez que si votre bande montante elle-même est le goulot. Le app/preferences du shim affiche le max_uploads_per_torrent de race ; setPreferences ne l'écrit pas.

[race.custom_choking] de la 3.x est toujours ignorée ; le démon la nomme dans un avertissement au démarrage qui renvoie vers choking = true et max_uploads_per_torrent.

start_paused = true dans la section d'un moteur (absente = false ; pas dans le modèle ; lue au démarrage) retient ce moteur à son démarrage : il ne contacte aucun pair et n'envoie aucune annonce (ni scrape) jusqu'à ce que vous le libériez. Un torrent déjà dans le calendrier d'annonces revérifie environ une fois par minute (60 s plus un étalement jusqu'à 6 s), donc il annonce environ une minute après la libération. Le calendrier admet un catalogue sur une durée allant jusqu'à une demi-heure après le démarrage (au moins 100 torrents par 10 s) ; un torrent pas encore admis quand vous libérez le moteur annonce quand il est admis.

• Un bandeau au-dessus des onglets, sur tous les onglets, impossible à fermer : Pause au démarrage : {engines} n'annonce rien (Startup pause: {engines} not announcing), « Aucune annonce ni connexion à un pair ne sort d'Hydranos. Ajuster les limites maintenant si besoin, puis démarrer. Les torrents mis en pause à la main le restent. », bouton Démarrer maintenant (Start now) (Démarrage… (Starting…) pendant l'opération). Il revérifie toutes les 10 secondes.
• API : GET /api/startup-pause → {"held": [...], "holding": true} ; POST /api/startup-pause/release → {"status": "ok", "released": [...], "holding": false}. Libérer deux fois est sans danger.
• /health répond degraded (toujours 200) tant qu'un moteur est retenu ; /api/engines porte start_paused pour chaque moteur.
• La retenue est par processus, pas par torrent : la libérer ne démarre pas les torrents que vous avez arrêtés.

Non implémenté en 4.4 : pas de positions dans la file — les appels de priorité répondent 409, et un Démarrer au-delà du plafond est de nouveau arrêté dans les 30 s — utilisez Forcer le téléchargement (setForceStart via le shim), un active_downloads plus grand ou dont_count_slow_torrents.

Bug connu en 4.4 : l'éditeur Paramètres avancés affiche de mauvaises indications pour hoard : max_connections default: 8000 (le modèle a 12000, absente vaut 0 = aucun plafond), max_uploads_per_torrent default: 20 (le modèle a -1, absente vaut 0 = 4 emplacements) et inactivity_timeout default: 90 (le modèle a 20, et la clé ne fait rien) — fiez-vous aux tableaux de cette page.

Accepté mais ignoré en 4.4 : inactivity_timeout (dans le modèle, 20 pour les deux moteurs) n'est lue par rien et n'est pas nommée au démarrage ; son indication dans l'éditeur, « Secondes avant qu'un pair au repos soit considéré comme inactif. » (Seconds before an idle peer is considered inactive.), ne décrit rien — le délai d'inactivité d'un pair est peer_timeout (absente ou 0 = 300 s, sous 120 relevée à 120, à chaud).

L'importeur qBittorrent ne reprend ni les limites de débit ni les limites de partage (Migrer depuis qBittorrent).

• Moteurs : race & hoard — ce qu'est un moteur, les rôles, les moteurs supplémentaires.
• Drain race & graduation — la déclaration Minimum seed qu'attendent les limites de partage.
• Shim qBittorrent & automatisation — chaque route et champ du shim.
• Config : moteurs & drain race — chaque clé de moteur.
• Workflows — les règles qu'une limite de partage ne sait pas exprimer.
• API REST — les routes natives.