Cette page liste tout ce qui, dans Hydranos 4.4, est un bouchon (stub), ignoré, cassé ou absent. Elle s'adresse à qui veut savoir, avant de compter sur un contrôle ou un réglage, s'il fait vraiment quelque chose.
Chaque ligne tient en une ligne. L'explication complète, avec ce qui se passe réellement et le contournement, est sur la page liée. Ce que la 4.4.1 a corrigé dans la liste de la 4.4.0 est résumé à la fin, dans Corrigé en 4.4.1, et ce que la 4.4 a corrigé dans la liste de la 4.3 dans Corrigé en 4.4.
Comment lire la colonne Statut
Statut
Signification
Non implémenté
Le contrôle, la route ou le réglage existe, mais ne fait rien (ou renvoie des constantes), ou la fonction s'arrête en deçà de ce que son nom suggère.
Accepté mais ignoré
Une clé ou un champ est accepté et enregistré, mais rien ne s'en sert. Depuis la 4.4, la plupart de ces clés sont nommées dans un avertissement au démarrage.
Bug connu
La fonction existe et marche, mais se comporte mal dans le cas décrit.
Absent
Cette fonction n'existe pas en 4.4, et rien dans l'interface ne laisse croire le contraire.
Piège par défaut
Ça marche, mais la valeur par défaut n'est pas celle que vous attendriez.
Bug de doc
Le produit marche ; un fichier livré avec lui le décrit de travers.
Les trois premiers correspondent aux encadrés utilisés sur toutes les pages (Non implémenté en 4.4, Accepté mais ignoré en 4.4, Bug connu en 4.4).
Dans l'interface web
Élément
Statut
À faire à la place
Page
Nulle part l'interface ne montre si les pairs peuvent joindre un moteur : la couleur du panneau réseau de l'en-tête ne reflète que la sonde de sortie, et son infobulle renvoie à un point de santé que la page ne dessine pas
Bug connu
GET /api/port-forward (engines[].reachable, inbound_peers)
Paramètres avancés liste [daemon] kill_switch, egress et les clés de [proxy], censées être laissées à l'onglet Réseau : l'éditeur ne masque les clés de l'onglet Réseau que sous [race]/[hoard]
Bug connu
Changez-les sur l'onglet Réseau, qui les écrit d'un bloc
Onglet d'ajout : revenir à - aucune - (- none -) dans Catégorie (Category) garde le Chemin d'enregistrement (Save Path) et le Mode de la catégorie précédente, et les envoie
Bug connu
Videz Chemin d'enregistrement et choisissez le mode à la main
Textes d'aide de l'onglet d'ajout : Put the payload in its own subfolder dit « on the hoard agent » (l'option vaut pour tout moteur) ; Skip the hash check… dit qu'un fichier manquant ou de mauvaise taille est refusé (rien n'est vérifié)
L'option de sous-dossier (create_subfolder, [daemon] create_torrent_folder) pour un magnet ajouté par POST /api/torrents ou l'onglet d'ajout, et pour les dossiers surveillés, les ajouts MCP, les magnets RSS, les rapatriements depuis un nœud et l'assistant d'import
Accepté mais ignoré
Envoyez le .torrent, ou ajoutez le magnet via le shim avec contentLayout=Subfolder
Ordre de téléchargement (séquentiel, premier/dernier morceau) à l'ajout : seul le shim le lit, pas l'onglet d'ajout, POST /api/torrents, la route d'upload, le MCP ni un dossier surveillé
Non implémenté
Réglez-le juste après l'ajout (menu contextuel ou download-order), ou ajoutez via le shim
Les clés de app/setPreferences autres que les limites de partage, les plafonds de débit, dht/pex/lsd, les nombres d'actifs, la règle des torrents lents et save_path répondent 200 et ne font rien (journalisé)
app/buildInfo et app/version sont des constantes ; seeds et total_wasted de torrents/properties valent 0 ; pas de vraie availability ; pas d'état ni de nombre de pairs par tracker dans torrents/trackers
rename, filePrio 0 et les appels de position dans la file répondent 409 ; sync/maindata est toujours une mise à jour complète ; renameFile, renameFolder, editTracker, setSuperSeeding, setAutoManagement, pieceStates, webseeds, search/*, log/* répondent 404
Le plafond de débit global du client ne se règle que par l'API qBittorrent (transfer/setUploadLimit, setPreferences) ; pas de limites de débit alternatives ni planifiées
Non implémenté
Plafonds par moteur dans les réglages, plafonds par torrent avec Limiter le débit… (Limit rate…)
L'horloge d'inactivité de max_inactive_seeding_time repart à chaque démarrage du démon ; l'action des limites de partage se règle par moteur seulement ; pas de super seeding
Sans max_connections, aucun plafond de connexions aux pairs, et sans active_downloads pour hoard, aucun plafond de téléchargements (modèle : 4000 / 12000, et 10)
Pas d'événement stopped quand un torrent part par graduation, déplacement de données ou Move to engine ›, ni lors d'un plantage ou d'un kill ; à l'arrêt, seul ce qui part en 5 s
Non implémenté
Arrêter (Stop) le torrent et attendre d'abord l'annonce
Les limites de partage (ratio, temps de seed, inactivité) n'agissent jamais sur un torrent dont le premier tracker vivant n'a pas de Minimum seed déclaré : le seed est maintenu, journalisé une fois
Piège par défaut
Déclarez le Minimum seed de chaque tracker sur l'onglet Trackers (0 pour aucun)
Paramètres avancés ne liste active_downloads, max_uploads_per_torrent et peer_timeout que si le fichier les contient, alors que l'enregistrement les créerait (le modèle de race n'a pas d'active_downloads)
Vérifier ce qui se passe vraiment (Check what actually happens) ne peut pas conclure à une fuite tant que le kill switch est armé (par défaut, dans tous les modes sauf Direct) : la route par défaut n'est pas mesurée, les lignes épinglées ou passant par un proxy affichent warn
Les appels aux autres nœuds, au serveur de contrôle gluetun, à un qBittorrent en cours d'import et le NAT-PMP/UPnP d'un moteur non épinglé restent locaux ; un moteur épinglé à une interface que Hydranos n'a pas créée résout les noms des trackers avec le résolveur de l'hôte
Non implémenté
WireGuard géré (le DNS de son fichier), ou tout le processus dans le VPN
bind_interface et le WireGuard géré sont réservés à Linux : refusés ailleurs par l'API et l'onglet Réseau (Network) ; un moteur dont le fichier définit encore bind_interface reste hors du réseau
[daemon] bind_interface sous Windows est accepté par l'onglet Réseau et POST /api/network/egress, puis toute requête du démon (listes, vérification de mise à jour, webhooks, URL de .torrent) qui n'emprunte pas la route d'un moteur est refusée, [proxy] compris
Bug connu
Laissez Interface du démon (Daemon interface) vide, utilisez [proxy]
GET /api/settings renvoie en clair une URL announce_proxy, user:pass compris, à quiconque détient la clé API (les mots de passe SOCKS5 et la clé d'API gluetun sont masqués)
Bug connu
Considérez que la clé API donne aussi cet identifiant
Un seul mode réseau par instance : gluetun pour un moteur et le WireGuard géré (ou un moteur direct) pour un autre ne peuvent pas partager un processus
Absent
Une seconde instance dans gluetun, déclarée comme nœud
La carte Proxy SOCKS5 (SOCKS5 proxy) dit « Personne ne peut vous joindre depuis l'extérieur » (Nobody can connect to you from outside) et que la DHT montre toujours votre adresse : les pairs entrants joignent toujours le port d'écoute de l'hôte, et la DHT est coupée derrière le proxy
WireGuard géré : démonter un tunnel retire ses règles oif et son périphérique, pas sa règle from (préférence 6100 plus l'emplacement), qui reste jusqu'à ce qu'un tunnel remonte à cet emplacement
Bug connu
Sans effet tant que la table reste vide ; ip rule del pref <6100+emplacement> à la main
Lignes d'un autre nœud : Modifier les tags › (Edit tags ›), Forcer le téléchargement et Limites de partage… (Share limits…) sont sautés ; Edit trackers dans le panneau de détail modifie la copie de cette instance du même hash
Les préférences RSS de qBittorrent (rss_refresh_interval…) et les champs de règle torrentContentLayout, skip_checking et les autres options de torrentParams
Un Re-annoncer (Reannounce) groupé ne nomme aucun moteur : pour un hash détenu par deux moteurs, il annonce la première copie trouvée, qui peut être l'autre (trouvé en lisant le code)
La condition de workflow progress vaut 0 pour un torrent arrêté sans carte des pièces (ajout en mode seed ou cross-seed ajouté arrêté, torrent complet rechargé arrêté après un redémarrage)
Un default.toml créé par la 4.3.0 contient [vpn_speedtest] interval_secs = 3600 : la 4.4 le lit et lance toutes les heures un test iperf3 contre un serveur public
Les moteurs supplémentaires ne figurent ni dans la comparaison A / B, ni dans les cartes d'annonce hoard, ni dans Pic de sources actives (Peak live seeds), ni dans la chronologie race et ses instantanés (moteur race uniquement)
Non implémenté
/metrics, le graphique Débit d'envoi (Upload Speed)
Rien sur la sortie réseau dans /metrics (état du tunnel, port redirigé, verdicts du kill switch, IP de sortie, fuite DNS), et un moteur dont les annonces attendent un port redirigé n'apparaît dans aucune métrique ni dans /health
Non implémenté
Interrogez les routes JSON avec la clé API ; alertez sur des annonces qui cessent de croître
Aucune mesure publiée au-delà d'environ 293 000 torrents (Hydranos 4.2) : mémoire, démarrage à froid, rythme d'annonces et durée d'arrêt à un million ne sont pas mesurés
Absent
Surveillez hydra_announce_late et hydra_memory_resident_bytes à mesure que le catalogue grandit
Routes de liste complète (GET /api/engines/:id/torrents, /api/hoard/torrents, /api/race/torrents) : un filtre plus un offset (limit absent ou à 5000 et plus) boucle sans fin dès que 5000 lignes correspondent à partir de cet offset
L'indication finale de packaging/install.sh, /opt/hydranos/hydranos-update, n'a pas --dir (lancé ailleurs, l'outil de mise à jour cherche dans le dossier courant)
Windows : l'icône de la zone de notification disparaît avant la fin de l'enregistrement de reprise ; fermer la console, un arrêt du système ou une déconnexion lancent le même enregistrement, mais Windows peut terminer le processus avant qu'il s'achève (non testé par le mainteneur)
Bug connu
Quittez depuis la zone de notification et attendez que hydranos.exe disparaisse du Gestionnaire des tâches
Windows : une mise à jour lancée alors qu'Hydranos est encore sur son écran de démarrage ne peut pas l'arrêter (pas encore d'événement d'arrêt, taskkill ignoré) : elle finit par still running after 60s, rien n'est remplacé (trouvé en lisant le code)
Bug connu
Attendez la fin de l'écran de démarrage avant de mettre à jour
Clés nommées dans un avertissement au démarrage avec leur remplacement (agent_token, listen_interfaces, file_pool_size, [race.custom_choking], [hoard.disk_slots], [bench], [metrics], [peer_intel], [arr_cleanup], [notify], min_age_minutes, blocs d'agent 3.x et champs de catégorie), masquées dans Paramètres avancés ; plus inactivity_timeout et announce_rate_limit, qui ne sont pas signalées : tableau complet
Déplacements :Déplacer vers un dossier… (Set location…), un déplacement de catégorie de même mode et l'action de workflow move files to a folder emportent l'état propre au torrent (pièces, modifications de trackers, compteurs, plafonds, état d'arrêt) au lieu de le ré-ajouter en mode seed ; Duplicate to engine › refuse (409) une source incomplète ou en cours de vérification ; une graduation, par le drain ou à la main, laisse un torrent en place quand un fichier du même nom se trouve à la destination ; la première annonce après une graduation ou un Move to engine › ne déclare plus les octets de toute la vie du torrent.
Ajout et catégories :Démarrer (Start) passe par la même garde de chemin qu'une revérification ; POST /api/torrents répond 400 ou 409 pour un refus et 500 seulement pour une panne du store ; un torrent ajouté pendant la réconciliation du store garde sa ligne (plus de fantômes no piece hashes), et DELETE /api/torrents/:hash retire un torrent qu'un moteur fait tourner sans ligne dans le store ; un PUT de catégorie sans mode garde le mode ; un renommage de catégorie la suit partout où elle est nommée.
File et shim :Forcer le téléchargement et setForceStart font passer un torrent devant la file de téléchargement (plus de 409).
Sécurité : les mots de passe SOCKS5 et la clé d'API gluetun sont masqués dans GET /api/network/mode, /api/network/egress et /api/settings.
Dossiers surveillés et interface web : chaque dossier est analysé à part (un partage réseau bloqué ne bloque plus les autres), le statut affiche vus N et pas encore scanné ; chemins UNC et C:/… acceptés sous Windows ; le moteur forcé d'un dossier conservé à l'enregistrement ; recharger l'onglet Config n'affiche plus une liste vide ; les puces de filtre gardent leur largeur.
Corrigé en 4.4
Pour qui met à jour depuis la 4.3.0 (la 4.4 inclut la 4.3.1 et la 4.3.2). Ce qu'il faut vérifier après la mise à jour est dans Mettre à jour depuis la 3.x.
Sécurité et accès :Changer le mot de passe (Change password) enregistre le nouveau mot de passe ; bouton Se déconnecter (Sign out) ; hydranos reset-password / hash-password ; la configuration initiale juge le pair de la socket, pas seulement X-Forwarded-For ; le mode de secours écoute sur api_host/api_port.
Arrêt et redémarrage : les redémarrages par l'interface ou l'API enregistrent les données de reprise et se terminent avec le code 75 ; un onglet ouvert de l'interface ne bloque plus l'arrêt propre ; HYDRANOS_STOP_TIMEOUT est appliqué ; sous Windows, la fermeture de la console, l'arrêt du système, la déconnexion et Ctrl+Break lancent un arrêt propre ; stopped est envoyé au retrait et à l'arrêt.
Déplacements et retraits : le Move to engine › local ajoute à la cible avant de retirer la source ; une graduation libère la source (données conservées), déplace les fichiers, puis ajoute à la cible, et annule tout en cas d'échec ou d'annulation ; les deux emportent l'état du torrent ; POST …/graduate fait les mêmes vérifications ; la purge race et la réconciliation après restauration ne suppriment que la copie du moteur concerné.
Interface web : groupe Node affiché avec deux moteurs locaux ; l'onglet Race liste chaque moteur de rôle race ; les actions groupées sur les lignes d'un moteur supplémentaire agissent sur ce moteur ; Paramètres avancés enregistre les tables de trackers ; le panneau réseau nomme les moteurs ; cartes, boîtes de dialogue et badges morts retirés ; le badge de mise à jour et Signaler un problème (Report issue) utilisent le bon dépôt.
Ajout et catégories :Mode, sous-dossier (pas pour un magnet), saut de la vérification de hash et Add without starting de l'onglet d'ajout sont appliqués ; torrent_url sur la route native ; mode seed pour les magnets ; codes de statut plus clairs ; renommage et suppression de catégorie (étiquettes effacées), Adopter (Adopt) pour les orphelines, mode insensible à la casse, Aucune catégorie (No category) ; provenance de l'import enregistrée.
Shim qBittorrent : vrais uploaded/ratio, tracker, hashes=all, createCategory 409, deleteTags, addTrackers qui annonce, moteurs supplémentaires listés une seule fois ; ajout de setLocation, setShareLimits, setForceStart, filePrio, du séquentiel, de sync/maindata, des limites de débit et de nombreuses clés de setPreferences.
Nouvelles fonctions : RSS, priorités de fichiers et téléchargement séquentiel, file de téléchargement, limites de partage, limites de débit, choker, LSD, scrape des torrents pas encore annoncés, WireGuard géré, modes Gluetun, SOCKS5 et PROXY-v2, kill switch et sortie du démon.
Moteurs et trackers :start_paused retient bien ; les annonces race suivent l'intervalle du tracker au lieu de 30 minutes ; DHT, PEX et webseeds actifs et vrais ports d'écoute quand les clés manquent ; modifications de trackers enregistrées tout de suite ; indication du formulaire de trackers corrigée ; + Hôte manuel (+ Manual host) laisse Minimum seed vide.
Réseau : changements de port à chaud enregistrés et réattachés (TCP, uTP, annonces, redirection) ; ports hors plage refusés ; vrai /api/port-forward ; UDP redirigé ; enable_ipv6 = false force les annonces en v4 ; chaque moteur ouvre ses connexions avec sa propre attache et sa propre identité ; uTP refusé plutôt que non épinglé ; announce_proxy / announce_ip lus ; HYDRANOS_CAP_NET_ADMIN utilisé.
Nœuds : actions sur les lignes distantes envoyées au nœud ; noms de nœuds avec trait d'union ; corrections du script d'enrôlement (nom de l'archive, pas de docker rm d'un conteneur étranger, version épinglée, jeton conservé sur un 409) ; job handoff persistant ; déplacements vers le moteur supplémentaire d'un nœud confirmés ; modification, renommage et rotation de clé d'un nœud.
Workflows et jobs :Enregistrer (Save) garde Enabled ; groupes NOT conservés ; data_missing corrigé et progress corrigé pour les torrents en marche (arrêtés : voir plus haut) ; colonne Toutes les (Every) ; chemins Windows ; contrôle allow_breaking_hardlinks ; indications des champs ; Annuler dans Jobs ; Actifs seulement (Active only) montre les jobs en file ; Vérifier à nouveau groupé atteint les copies race.
Supervision : filtres de Journaux (Logs) et En direct (Live) ; rotation du journal (128 Mio, 4 anciens fichiers) ; vrais /health et /api/startup ; /metrics complet ; vrais compteurs d'anomalies ; test de ligne, comparaison A / B et instantanés race enregistrés ; moteurs supplémentaires dans Vue d'ensemble (Overview), Performances (Benchmark), Records et la santé des trackers ; les routes de liste respectent les filtres ; routes bouchons retirées.
Packaging et restes de la 3.x :packaging/install.sh installe l'outil de mise à jour et n'écrase plus une unité existante (celle livrée va dans hydranos.service.new) ; commentaires de docker-compose.yml corrigés ; /api/agents* et jobs/move-remote répondent 410 avec le remplacement ; HYDRANOS_ENGINE_ID / HYDRANOS_ENGINES refusés avec un message ; clés mortes nommées au démarrage.