🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Pour tous ceux qui seedent sur des trackers avec Hydranos, privés avant tout : l'onglet Trackers, la modification de la liste de trackers d'un torrent, et ce qu'Hydranos envoie à un tracker et quand : quels réglages s'appliquent par hôte, quel événement part à chaque étape, et ce qu'il ajoute autour des annonces (un scrape pour les torrents pas encore annoncés, stopped à la suppression et lors d'un arrêt propre).

Ce qui distingue en général les moteurs race et hoard : Moteurs : race & hoard. Obligations de seed et drain : Drain race & graduation. Vocabulaire : Concepts & glossaire.

L'onglet Trackers affiche une ligne par hôte de tracker (par exemple tracker.example.org), et non une ligne par URL. Une ligne apparaît quand :

• un torrent du catalogue nomme cet hôte, qu'il lui ait déjà été annoncé ou non (vous pouvez donc définir une passkey avant la première annonce) ;
• ou une annonce vers lui a réussi ou échoué ;
• ou vous avez enregistré pour lui une passkey ou une famille IP d'annonce.

Les lignes cumulent tous les moteurs de cette instance. Le décompte du catalogue utilise l'hôte tel qu'il est écrit dans l'URL, mais les erreurs, les auto-vérifications, le disjoncteur et la correspondance passkey/famille utilisent l'hôte en minuscules : un Tracker.Example.org en échec affiche ses erreurs sur une ligne tracker.example.org distincte.

Règles de gravité :

• needs action (rouge) : le tracker a rejeté la passkey (invalid_passkey), ou l'auto-vérification n'a pas trouvé cette instance dans la liste de pairs d'une famille d'adresses (v4_missing, v6_missing) ou des deux (absent).
• unreachable (orange) : erreurs rate_limited, timeout, dns ou connect.
• Les torrents que le tracker ne connaît plus (unknown_torrent) ne sont pas comptés comme une panne : il n'y a rien à corriger côté tracker.

L'onglet porte un badge rouge ou orange indiquant le nombre de trackers rouges ou orange, compté en trackers distincts sur l'ensemble des moteurs (un tracker rouge à la fois sur race et sur hoard compte une fois ; le rouge l'emporte sur l'orange). Chaque moteur alimente les compteurs d'erreurs, les gravités et le badge, moteurs supplémentaires compris (voir Supervision & journaux).

Auto-vérification : un seed ne demande normalement aucun pair à un tracker. Une annonce de seed sur 64 (un seul compteur pour tout le processus) demande 50 pairs et note si l'adresse de cette instance figure dans la liste. Tant qu'un hôte n'a pas de verdict, chaque annonce de seed vers lui demande 50 pairs, de même qu'un seed trouvé absent des deux familles. Le verdict (ok, unknown, v4_missing, v6_missing, absent) est une étiquette dans la cellule Statut (Status) ; son âge et la taille de l'essaim sont dans l'info-bulle de l'étiquette. unknown n'est pas une erreur et s'affiche en gris : un tracker peut exclure le pair demandeur de sa propre réponse, donc une absence seule ne prouve rien ; c'est v4_missing / v6_missing (une famille vue, pas l'autre) qui signale un problème.

Cliquer sur un nombre de la colonne Erreurs (1 h) (Errors (1h)) ouvre Errors in the last hour: <host> : par moteur et par classe, les messages du tracker lui-même (URL et passkeys masquées), le nombre, l'âge, l'événement et le torrent. Pour le moteur hoard, Show the torrents ouvre l'onglet Hoard filtré sur ce tracker et cette erreur.

Il existe deux jeux distincts de noms de classes :

La classe côté torrent est la dernière erreur de chaque torrent, effacée par la prochaine annonce réussie : c'est un état courant, pas un historique.

Cliquez sur Edit sur une ligne, ou sur + Hôte manuel (+ Manual host) pour un hôte qui n'a pas encore de ligne. Le formulaire contient :

Enregistrer (Save) écrit les trois réglages dans le fichier de configuration et les applique à chaud. Chaque torrent prend en compte une nouvelle passkey ou famille IP à sa propre prochaine annonce, si bien qu'un changement se propage sur un intervalle (30 minutes par défaut) ; faites Re-annoncer (Reannounce) sur un torrent pour vérifier tout de suite.

Comment chaque réglage est mis en correspondance avec les URL de trackers d'un torrent :

• Passkey : correspond à l'hôte lui-même ou à n'importe lequel de ses sous-domaines (tracker.example.org couvre aussi announce.tracker.example.org). Quand plusieurs clés correspondent, la plus longue l'emporte. Ce n'est pas une recherche de sous-chaîne. La passkey remplace le dernier segment du chemin de l'URL, de sorte que https://tracker.example.org/announce/OLDKEY est annoncé comme https://tracker.example.org/announce/0123456789abcdef. Seul un chemin dont le dernier segment est exactement announce (ou vide) est laissé tel quel. La query string est conservée mais pas lue : https://tracker.example.org/announce.php?passkey=OLD devient https://tracker.example.org/0123456789abcdef?passkey=OLD ; ne définissez donc pas de remplacement pour un tracker qui porte sa passkey dans la query.
• Announce (famille IP) : même règle hôte-ou-sous-domaine. auto envoie une annonce par famille d'adresses, avec le même peer id, et fusionne les réponses. Fixez un hôte sur v4 ou v6 si le tracker ne vous voit que dans une famille. auto est enregistré comme « aucune entrée ».
• Minimum seed : hôte exact uniquement, et seul compte l'hôte de la première URL de tracker du torrent. Cela ne change pas ce qui est annoncé : cela indique au drain race quand un torrent race peut être supprimé. Vide (non déclarée) protège le torrent de la suppression ; 0 le libère. Détails dans Drain race & graduation.

L'aide sous Hôte (Host) le dit : tel qu'affiché dans la colonne Tracker ; passkey et famille IP couvrent aussi ses sous-domaines (as shown in the Tracker column; passkey and IP family also cover its subdomains).

Un moteur avec enable_ipv6 = false n'annonce qu'en IPv4, quelle que soit la famille de l'hôte (auto et v6 only compris). Voir Réseau : ports & redirection.

• Mute garde la ligne et retire le tracker des compteurs rouge/orange et du badge de l'onglet (statut acknowledged).
• Masquer (Hide) retire la ligne du tableau et du badge. Le tracker reçoit toujours les annonces. Les lignes masquées sont listées sous Trackers masques (Hidden trackers), avec Afficher (Unhide) par ligne et Unhide all.
• Hide unconfigured trackers holding fewer than [10] torrents + Hide them masque tous les trackers sous ce nombre qui n'ont ni passkey ni famille autre que auto (les trackers publics intégrés à des fichiers .torrent égarés). Un hôte doté d'une passkey ou d'une famille IP n'est jamais masqué de cette façon.

La carte Statistiques par tracker (Per-tracker stats) ventile le trafic par hôte de tracker et par moteur (↑ rate, ↓ rate, Pairs (Peers), Actifs/Total (Active/Total), Seedsize (Seed size), ↑ total / ↓ total cumulés, Ratio). Graphique du tracker (Tracker chart) trace l'envoi d'un tracker dans le temps (hoard ↑, race ↑).

L'onglet écrit ces tables dans default.toml (les clés sont des hôtes de trackers, les valeurs des chaînes) :

[announce_passkeys]
"tracker.example.org" = "0123456789abcdef"

[announce_ip_modes]
"tracker.example.org" = "v4"

[announce_min_seed_hours]
"tracker.example.org" = "72"

[announce_muted] et [announce_hidden] prennent "tracker.example.org" = "1".

Depuis la 4.4, Config › Paramètres avancés (default.toml) (Advanced settings (default.toml)) peut aussi modifier les entrées existantes de ces cinq tables (passkeys et familles IP dans le sous-onglet Trackers et réseau (Trackers & Network), les trois autres dans Other ; une clé d'hôte entre guillemets est mise en correspondance par son nom nu). Il ne peut pas ajouter d'hôte : utilisez pour cela l'onglet Trackers. Un tel enregistrement répond qu'un redémarrage est nécessaire. Les changements faits depuis l'onglet Trackers ou ses routes d'API s'appliquent à chaud. Chacun de ces enregistrements relit aussi tout le fichier dans la configuration en cours, modifications manuelles comprises, mais redémarrer est la façon fiable d'appliquer une modification manuelle. Valeurs par défaut et toutes les autres clés : Config : démon, auth & global.

Les mêmes actions via l'API REST (toutes exigent la clé API, voir API REST) :

curl -X POST -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"host":"tracker.example.org","passkey":"0123456789abcdef"}' \
  http://hydranos.example.org:8199/api/announce/passkeys

Même forme pour POST /api/announce/ip-modes ({"host","mode":"v4"}) et POST /api/announce/min-seed ({"host","hours":72}). Une passkey vide supprime le remplacement ; {"host":"…","clear":true} sur min-seed la rend de nouveau non déclarée. POST /api/announce/mute prend {"host","muted"} et POST /api/announce/hidden prend {"host","hidden"} ou {"hosts":[…],"hidden":true}. GET /api/trackers renvoie les lignes de l'onglet ; GET /api/announce/health et GET /api/announce/errors?host=… renvoient les gravités et le détail des erreurs.

Ouvrez le panneau de détail d'un torrent. La carte Trackers affiche :

• Announced as : le peer id avec lequel ce torrent a annoncé pour la dernière fois, et quand (avant la première annonce : Not announced yet since this engine started et l'id qu'il utilisera). Une ligne Next announce n'apparaît que si le prochain peer id diffère, ce qui n'arrive pas en usage normal.
• le tableau Tracker, Statut (Status), Last, Suivant (Next), Scrape. Statut vaut OK, pas encore annoncé (not announced yet) ou le message d'erreur. Last et Suivant (Next) sont la dernière annonce réussie et la prochaine prévue (ou une estimation tirée de la file juste après le démarrage). Scrape affiche seeders/leechers (12s/3l), tirés des réponses d'annonce ou, pour un torrent auquel aucun tracker n'a encore répondu, d'un scrape (voir Scrape pour les torrents pas encore annoncés).

Ces valeurs sont celles du torrent, pas de chaque URL : toutes les lignes affichent la même chose, si bien qu'une URL de secours morte paraît en bonne santé. Les erreurs par hôte de l'onglet Trackers permettent de les distinguer.

Edit trackers ouvre une zone de texte :

• une URL par ligne ;
• une ligne vide commence un nouveau palier (tier). Les paliers sont essayés dans l'ordre (voir Annonces race et hoard plus bas) ;
• schémas acceptés : http://, https:// (exigent un hôte) et udp:// (exige un hôte et un port, par ex. udp://tracker.example.org:6969/announce). Tout le reste est refusé avec une erreur. Les URL sont rognées, pas réécrites ;
• l'éditeur indique la copie de quel moteur vous modifiez (Engine: race, par exemple).

Save trackers remplace toute la liste (une liste identique répond No change to save.). Un tracker ajouté reçoit son propre started à la prochaine annonce du torrent, pas au moment de l'enregistrement.

À savoir :

• Survit à un redémarrage. Save trackers écrit aussitôt la nouvelle liste dans l'état de reprise du moteur (voir Architecture), et cet état l'emporte sur le .torrent au démarrage. Le .torrent stocké n'est pas réécrit.
• Un torrent ajouté à l'instant peut refuser une modification avec this torrent has no stored .torrent yet ; réessayez un peu plus tard.
• Une seule copie. Si le même torrent est dans plusieurs moteurs, la modification s'applique au premier moteur qui le détient (race, puis hoard, puis les moteurs supplémentaires).
• Lignes distantes : la modification ne cherche que dans les moteurs locaux : elle change la copie locale s'il y en a une, et échoue avec torrent not found sinon ; la copie du nœud n'est jamais modifiée (voir Nœuds & plusieurs machines).

Via l'API REST :

# Read the live list (also returns engine and peer id state)
curl -H "X-Api-Key: YOUR_API_KEY" \
  http://hydranos.example.org:8199/api/torrents/<info_hash>/trackers

# Add one URL as a new tier
curl -X POST -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"op":"add","urls":["udp://tracker.example.org:6969/announce"]}' \
  http://hydranos.example.org:8199/api/torrents/<info_hash>/trackers

op vaut add (chaque URL dans un nouveau palier, doublons ignorés), remove (les paliers vides disparaissent), replace (from → to, erreur si from est absent) ou set (avec tiers, un tableau de tableaux). La réponse est {"trackers": <tiers>, "changed": true|false}. Les routes torrents/addTrackers et torrents/removeTrackers du shim qBittorrent passent par le même chemin (voir Shim qBittorrent & automatisation).

Ce que chaque moteur envoie dans ses annonces :

Une annonce HTTP a un délai d'expiration de 15 s. Hydranos comprend interval, min interval, peers / peers6, complete / incomplete, failure reason, warning message (journalisé), tracker id et le retry in de BEP 31.

• Famille IP : avec auto, une annonce part par famille d'adresses ; se règle par hôte dans l'onglet Trackers.
• Peer id vis-à-vis des pairs : chaque moteur annonce et fait ses handshakes (entrants et sortants) avec son propre peer id, donc le pair que liste un tracker est bien le pair qui se connecte.
• Quel chemin réseau : les annonces d'un moteur sortent par le même chemin que ses pairs : épinglées à son bind_interface sous Linux (ou à son tunnel WireGuard géré), via son announce_proxy s'il est défini, sinon via son proxy SOCKS5 de pairs (socks5h://, le nom du tracker résolu par le proxy). TYPHON_ANNOUNCE_PROXY n'est qu'un repli pour un moteur qui n'a ni l'un ni l'autre. Une URL de proxy illisible fait échouer l'annonce (announce proxy … is not usable) ; elle ne retombe jamais sur une annonce directe. Détails : VPN & sortie réseau et WireGuard géré.
• Annonces retenues : un moteur retenu au démarrage (start_paused) ou qui attend son port redirigé (Gluetun, WireGuard géré) n'annonce rien, et revérifie environ une fois par minute.
• Pas d'usurpation de client. Hydranos ne présente jamais le peer id ni le User-Agent d'un autre client. Une ancienne table [announce_clients] est supprimée au premier démarrage d'une 4.3 ou ultérieure, ce qui arrête une fois les torrents de ces trackers : redémarrez-les après la mise à jour.

La requête complète, avec la spécification de chaque champ, se trouve dans BITTORRENT-CONFORMANCE.md. Son exemple montre la 4.2.4 (-HY4240-), et trois de ses passages sont périmés en 4.4 : le « we never scrape » de BEP 48 et la section sur le scrape (voir plus bas), et « Magnet links are not resolved » (les magnets sont résolus).

flowchart LR
    CAT["Catalogue du moteur<br/>relu toutes les 10 s"] --> ADM["Quota d'admission<br/>max(total x 10 / 1800, 100) par 10 s"]
    ADM --> Q["File par hôte du premier tracker<br/>concurrence adaptative de 4 à 2048"]
    BUMP["Événements et Re-annoncer manuel"] --> Q
    Q --> HELD{"Moteur retenu ?<br/>start_paused ou port pas encore connu"}
    HELD -- "oui, nouvelle vérification dans 1 min environ" --> Q
    HELD -- "non" --> BRK{"Disjoncteur de l'hôte ouvert ?<br/>5 échecs = pause de 10 min"}
    BRK -- "oui" --> SKIP["Tracker sauté pour ce passage"]
    SKIP --> RES
    BRK -- "non" --> CLI["Annonce HTTP ou UDP"]
    CLI --> TRK["Tracker"]
    TRK --> RES["Replanification<br/>intervalle plus gigue<br/>race refusé : 5 s"]
    RES --> Q

Ré-annonce manuelle : Re-annoncer (Reannounce) dans le menu contextuel de la liste Race ou Hoard, ou :

curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
  http://hydranos.example.org:8199/api/torrents/<info_hash>/reannounce

Une ré-annonce manuelle franchit le min interval d'un tracker, mais jamais son retry in / Retry-After. Elle répond {"status":"ok","bumped":true}, in_flight si une annonce est déjà en cours, 429 avec cooldown et retry_after_secs dans les 60 s qui suivent la précédente relance de ce torrent (la vôtre, ou celle que provoque un Arrêter, un Démarrer ou un completed), 429 si la file est pleine, 503 si le moteur n'annonce pas, et 202 avec "status":"queued","bumped":false si le planificateur n'a pas répondu en 5 s. La route torrents/reannounce du shim qBittorrent fait de même pour chaque copie du torrent.

Un moteur de rôle race revient plus tôt que l'intervalle seulement tant qu'un tracker refuse encore un torrent qu'il n'a pas enregistré : voir Annonces race et hoard.

Les événements sont suivis par torrent et par tracker :

sequenceDiagram
    participant U as Vous
    participant H as Moteur Hydranos
    participant T as Tracker
    U->>H: Ajout du torrent
    Note over H: délai de démarrage 5 s, puis admission<br/>(environ 30 min, la première annonce peut venir plus tard)
    H->>T: annonce event=started
    loop à chaque intervalle (30 min par défaut, plus gigue)
        H->>T: annonce (sans événement)
    end
    Note over H: fin du téléchargement
    H->>T: annonce event=completed (immédiate, retentée jusqu'à livraison)
    U->>H: Arrêter
    H->>T: annonce event=stopped (tentée une fois)
    U->>H: Démarrer
    H->>T: annonce event=started (compteurs à zéro)
    U->>H: Supprimer
    H->>T: annonce event=stopped (tentée une fois, en arrière-plan)
    Note over H,T: arrêt propre : stopped à chaque tracker qui a reçu started,<br/>moteurs race d'abord, 5 s au plus

• started : la première annonce d'une session vers chaque tracker : après un ajout, après un redémarrage, après Démarrer (Start), ou pour un tracker ajouté à la liste.

• completed : dû à chaque tracker ayant vu started quand la dernière pièce d'un téléchargement est vérifiée ; non envoyé pour un torrent déjà complet au début de sa session (mode seed, revérification, cross-seed). Retenté à chaque annonce jusqu'à livraison, mais seulement en mémoire : un redémarrage avant qu'il n'aboutisse le fait perdre.

• stopped : envoyé immédiatement quand vous faites Arrêter (Stop) sur un torrent, tenté une fois par tracker, à chaque tracker qui a reçu started. Également envoyé :

  • quand un torrent est supprimé (depuis l'interface, l'API, le shim qBittorrent, le drain race, une purge race, un workflow ou une limite de partage) : en arrière-plan, une fois par tracker, 20 s au plus, avec les compteurs de la session et le trackerid s'il en a reçu un ;
  • lors d'un arrêt propre (SIGTERM, Restart depuis l'interface ou l'API, un arrêt pendant le démarrage) : les torrents démarrés de chaque moteur, moteurs de rôle race d'abord, 64 à la fois, en 5 s au total. Ce qui ne part pas à temps est laissé à l'expiration propre au tracker. La ligne de journal stopped sent to the trackers donne departed et of ;
  • les trackers udp:// sont ignorés quand le moteur a enable_udp_trackers = false.

  Il est aussi envoyé quand un torrent passe en erreur parce que ses données ont disparu. Il reste alors silencieux (rien ne revérifie les données) et n'annonce de nouveau started qu'après qu'un Vérifier à nouveau (Recheck) que vous lancez a retrouvé les données. Les torrents arrêtés avant un redémarrage n'envoient pas de second stopped au démarrage.

• Les événements n'attendent pas le prochain intervalle : le torrent est mis en file pour une annonce immédiate (au plus une fois par minute par torrent).

Non implémenté en 4.4 : un événement stopped quand un torrent quitte un moteur par graduation, par un déplacement de données (job move_data) ou par Move to engine ›, ou quand Hydranos plante ou est tué — le tracker cesse simplement d'avoir des nouvelles de ce pair et fait expirer l'entrée — si un tracker exige un départ propre, faites Arrêter (Stop) sur le torrent et attendez d'abord l'annonce.

L'uploaded que reçoit un tracker est un total de session, compté depuis le started de cette session. Hydranos ne rapporte uploaded qu'aux annonces, et une nouvelle session (started, compteurs à zéro) commence après chaque redémarrage. Une suppression et un arrêt propre envoient stopped avec les compteurs de la session, donc cet envoi est rapporté. Il n'est pas rapporté (au pire, un intervalle, 30 minutes par défaut, d'envoi par torrent et par tracker) après un crash ou un kill, une graduation, un déplacement de données ou un Move to engine › (ceux-ci ré-ajoutent le torrent ailleurs sans stopped), ni à l'arrêt pour ce qui n'est pas parti dans le budget de 5 s. Les compteurs cumulés d'Hydranos lui-même ne sont pas affectés. Sur un très gros catalogue, faites Arrêter (Stop) sur les torrents qui comptent et attendez leurs annonces avant un arrêt planifié.

Le rôle du moteur décide jusqu'où un passage descend dans la liste des trackers :

Cela couvre le cas race où le .torrent arrive avant que le tracker ait enregistré l'upload. La fenêtre de nouvelles tentatives se règle par moteur dans sa section ([race], ou celle d'un moteur supplémentaire de rôle race), lue au démarrage du moteur (redémarrez pour la changer), sans champ dans l'interface :

[race]
registration_retry_minutes = 6

0 (ou absent) signifie la valeur par défaut, 6 minutes, pas « désactivé ». Le compteur de refus s'arrête à 255, donc toute valeur au-delà de 21 minutes environ se comporte comme 21. La clé n'a aucun effet sur un moteur de rôle hoard. Plus sur les rôles : Moteurs : race & hoard.

Les trackers udp:// reçoivent des annonces (BEP 15, avec BEP 41 pour que le chemin et la passkey atteignent le tracker).

• Interrupteur par moteur : enable_udp_trackers dans [race], [hoard] ou la table de session d'un moteur supplémentaire. Absent signifie activé. Lu au démarrage du moteur. Désactivé, les URL udp:// sont ignorées silencieusement.
• Un client UDP pour la route par défaut, plus un par interface sur laquelle un moteur est épinglé : les annonces UDP d'un moteur partent de son bind_interface (ou de son tunnel WireGuard géré), comme ses annonces HTTP.
• La connexion et l'annonce sont chacune tentées deux fois (3 s, puis 5 s), puis l'annonce suivante réessaie, sous le même disjoncteur et les mêmes planchers qu'en HTTP. Les réponses UDP n'ont pas de min interval ; un intervalle de 0 signifie 30 minutes.
• Quand les annonces du moteur passent par un proxy (son announce_proxy, son proxy SOCKS5 de pairs, ou le repli TYPHON_ANNOUNCE_PROXY), les annonces UDP ne sont pas envoyées : elles échouent avec UDP trackers do not go through a SOCKS5 proxy (no UDP ASSOCIATE): they will not be announced while this proxy is active, classe udp_proxied (affichée sous la forme de cette phrase dans la cellule Erreurs (1 h) de l'onglet Trackers), pour que le tracker ne voie jamais votre vraie adresse à côté du proxy (voir VPN & sortie réseau).

Les nombres de seeders et de leechers (la colonne Scrape, les colonnes d'essaim des listes, les num_seeds / num_complete / num_incomplete du shim qBittorrent, les champs num_seeds, swarm_seeds et swarm_leechers des Workflows) viennent des champs complete / incomplete des réponses d'annonce, rafraîchis à chaque annonce. Un torrent auquel aucun tracker n'a encore répondu (en attente dans la file après le démarrage, ou arrêté) afficherait des zéros ; depuis la 4.4, un scrape (BEP 48 en HTTP, BEP 15 en UDP) remplit ces nombres, et seulement eux.

flowchart LR
    START["Démarrage du moteur"] --> WAIT["90 s"]
    WAIT --> HELD{"Moteur retenu ?<br/>start_paused"}
    HELD -- "oui" --> SLEEP["Attente de 300 s"]
    HELD -- "non" --> PICK["Jusqu'à 5000 torrents sans réponse d'annonce,<br/>non scrapés dans la dernière heure"]
    PICK --> TGT["Premier tracker scrapable dans l'ordre des paliers<br/>dont le disjoncteur d'hôte est fermé"]
    TGT --> REQ["50 hash par requête, 2 s d'écart par tracker,<br/>8 trackers à la fois"]
    REQ --> FILL["Seeders et leechers enregistrés,<br/>sauf si une annonce a répondu entre-temps"]
    FILL --> SLEEP
    SLEEP --> HELD

• Une boucle par moteur, à côté de son planificateur d'annonces. Non configurable et impossible à désactiver ; aucune clé n'existe.
• Quelle URL : en HTTP, le dernier segment du chemin doit commencer par announce, qui devient scrape (https://tracker.example.org/announce.php?passkey=X → https://tracker.example.org/scrape.php?passkey=X ; la query est conservée) ; tout autre chemin n'est pas scrapé. Le remplacement de passkey de l'onglet Trackers s'applique. Un tracker udp:// est scrapé sauf si enable_udp_trackers = false.
• Quel chemin : le même que pour les annonces du moteur : son interface, son proxy, rien tant que le moteur est retenu au démarrage (start_paused) (un moteur qui attend seulement son port redirigé scrape bien : un scrape ne porte aucun port), rien vers un hôte dont le disjoncteur est ouvert, pas de scrape UDP derrière un proxy.
• Ce qu'il ne fait pas : il ne compte jamais comme une annonce. Rien de ce qui attend une première annonce (le planificateur, la chronologie race, les lignes et les erreurs de l'onglet Trackers) ne le voit ; il ne démarre et n'arrête rien. Un torrent déjà annoncé n'est jamais scrapé. La première erreur d'un tracker met fin au tour de ce tracker ; les torrents qu'il n'a pas traités sont de nouveau scrapés au plus tôt une heure plus tard.
• Une ligne de journal INFO par passage qui avait des torrents à scraper : scrape: swarm counts for torrents not announced yet avec filled.

Il n'existe pas de modification groupée dans le menu contextuel. Utilisez un workflow avec l'action add trackers (add_trackers) : des URL d'annonce et/ou l'URL d'une liste à récupérer (une par ligne, récupérée au plus une fois par jour, 500 URL et 1 Mio maximum), chacune dans un nouveau palier. Elle ne touche jamais un torrent privé. Voir Workflows.

Plus : Dépannage. Chiffres et journaux d'annonce (announce failed, tracker warning) : Supervision & journaux.