RSS and Automatic Downloads FR

RSS et téléchargements automatiques

S'applique à Hydranos 4.4.

Pour tous ceux qui veulent qu'Hydranos récupère tout seul les nouvelles sorties depuis le flux RSS d'un tracker, comme le fait le téléchargeur RSS de qBittorrent. Vous verrez ce que sont un flux et une règle, où les régler dans l'onglet RSS, comment une règle décide de prendre un article, par quel chemin réseau un flux est récupéré, ce que change la section [rss], quelles routes d'API existent (natives et compatibles qBittorrent), et ce qui manque encore en 4.4. Vocabulaire : Concepts & glossaire.

Le RSS est nouveau en 4.4 : Hydranos 4.3 n'avait aucun RSS.

Ce que cela fait

Un flux (feed) est une URL qui renvoie du RSS 2.0 ou de l'Atom (le RSS d'un tracker, en général avec votre passkey dedans). Hydranos le récupère à son propre intervalle et garde ses éléments, appelés articles.
Une règle (une règle de téléchargement automatique) est le document de règle de qBittorrent : des filtres de texte, un filtre d'épisodes facultatif, les flux qu'elle surveille, et où ajouter ce qu'elle prend (une catégorie, éventuellement un chemin de sauvegarde).
Quand une règle correspond à un article, le torrent de l'article est ajouté par le même pipeline d'ajout que tout autre ajout : la catégorie choisit le moteur et le dossier, la réservation de chemin, la dédup et les workflows « à l'ajout » s'appliquent (Ajouter des torrents & données existantes).

En avez-vous besoin ? Sonarr, Radarr et autobrr lisent le RSS eux-mêmes et envoient leurs choix définitifs à Hydranos par torrents/add : ils n'ont besoin de rien sur cette page. Elle sert aux installations sans eux, et aux outils ou scripts qui pilotent le téléchargeur RSS de qBittorrent lui-même par /api/v2/rss/* — ces routes existent en 4.4 (voir API).

Ce qui distingue Hydranos d'une installation RSS qBittorrent ordinaire :

Un flux et ses fichiers .torrent sont récupérés par le chemin réseau du moteur où ira le torrent (tunnel, interface ou proxy), pas par la route par défaut de l'hôte. Voir Par quelle sortie passe un flux.
Un article pris une fois (ajouté, déjà présent ou refusé) n'est plus jamais repris par aucune règle : il est mémorisé par son guid et par son lien torrent, si bien qu'un flux qui republie le même lien sous un nouveau guid ne l'ajoute pas deux fois. Ce qui a été pris reste mémorisé quand le flux est supprimé.
Un refus du pipeline d'ajout est définitif ; un échec réseau est retenté. Voir Ce que devient un article.

Les flux, dossiers, articles, règles et l'enregistrement de ce qui a été « pris » sont stockés dans hydra.db (tables rss_feeds, rss_folders, rss_articles, rss_rules, rss_taken) et survivent à un redémarrage.

L'onglet RSS

L'onglet RSS se trouve entre Workflows et Trackers. Il est chargé quand vous l'ouvrez et après chaque action, pas rafraîchi chaque seconde ; après Tout rafraîchir (Refresh all), il se recharge encore une fois 3 secondes plus tard. Comme les autres onglets, il peut être masqué dans Config › Personnalisation (Personalisation).

Section Flux RSS (RSS feeds) :

Élément	Ce qu'il fait
Tout rafraîchir	Récupère chaque flux en arrière-plan (`POST /api/rss/refresh`).
+ Flux (+ Feed)	Ouvre le formulaire de flux : URL (texte indicatif `https://tracker.example/rss?passkey=...`), Nom (Name ; `Dossier\Nom regroupe les flux ; vide = l'hôte`), Rafraîchir toutes les (Refresh every ; `minutes, 5 au minimum`, prérempli avec la valeur par défaut, 30), Enregistrer (Save), Annuler (Cancel).
Bandeau rouge	`Le RSS est coupé par [rss] enabled = false : les flux sont gardés, rien n'est récupéré ni ajouté.` — affiché quand `[rss] enabled = false`. Vrai pour la partie automatique seulement, voir Bugs connus.
Tableau des flux	Flux (Feed : chemin, URL masquée, titre propre du flux), État (State), Dernier rafraîchissement (Last refresh), Articles (`{u} non lus sur {n}`), Toutes les (Every ; `{m} min`), et par ligne Articles, Rafraîchir (Refresh), Modifier (Edit), Supprimer (Delete ; supprime le flux et ses articles après une confirmation).

État affiche, dans cet ordre : rafraîchissement... ; bloqué par le kill switch (survolez pour la raison) ; la dernière erreur ; pas encore récupéré ; sinon OK avec via … (le chemin réseau utilisé).

Articles ouvre le panneau Articles de {name} (Articles of {name}) : Télécharger dans la catégorie (Download to category ; un sélecteur de catégorie, - aucune - par défaut), Tout marquer comme lu (Mark all read), Fermer (Close), et un tableau Date, Titre (Title ; lié à la page de l'article quand il en a une), Taille (Size ; vide quand le flux ne la donne pas), État (nouveau, lu, ou pris par {rule} : {outcome}), avec un bouton Téléchargement (Download) par article (grisé quand l'article n'a pas de lien torrent). Téléchargement ajoute cet article tout de suite, par le même chemin qu'une règle, dans la catégorie choisie au-dessus ; la ligne de résultat dit Ajouté : {title} ou Déjà dans ce client : {title}. L'article est ensuite enregistré comme pris par (manual), si bien qu'aucune règle ne l'ajoute plus tard. L'onglet n'envoie que l'article et la catégorie : pas de chemin de sauvegarde, jamais en pause (l'API accepte les deux, voir API).

Section Règles de téléchargement automatique (Automatic download rules) : + Nouvelle règle (+ New rule), puis le tableau des règles Activé (Enabled ; une case à cocher cliquable), Nom, Doit contenir (Must contain ; avec pas : … en dessous pour Ne doit pas contenir), Catégorie (Category), Flux (Feeds), Dernière correspondance (Last match), et par ligne Modifier, Supprimer.

Le formulaire de règle :

Champ	Clé du document de règle	Remarques
Nom	(le nom de la règle)	Renommer dans le formulaire renomme la règle, puis l'enregistre.
Catégorie — `choisit le moteur et le dossier`	`assignedCategory` / `torrentParams.category`	`- aucune -` = pas de catégorie : voir Où va un torrent ajouté.
Doit contenir (texte indicatif `show 1080p\|show 2160p`)	`mustContain`	Voir Filtres.
Ne doit pas contenir (Must not contain ; texte indicatif `cam\|hdts`)	`mustNotContain`
Filtre d'épisodes (Episode filter) — `1x1-10;12;20-; ou S01E01-S01E10`	`episodeFilter`
Ignorer les correspondances suivantes pendant (Ignore later matches for) — `jours, 0 = jamais`	`ignoreDays`
Dossier d'enregistrement (Save path) — `facultatif, sinon celui de la catégorie`	`savePath` / `torrentParams.save_path`
Activé (coché par défaut)	`enabled`
Utiliser des expressions régulières (Use regular expressions)	`useRegex`
Filtre d'épisodes intelligent (Smart episode filter)	`smartFilter`
Ajouter en pause (Add paused)	`addPaused` / `torrentParams.stopped`
Flux (une case par flux)	`affectedFeeds` (les URL des flux)	Une règle ne voit que les flux cochés ici.

Boutons : Aperçu (Preview), Enregistrer, Annuler. Aperçu liste, flux par flux (50 titres au plus par flux), les articles déjà récupérés auxquels le brouillon correspondrait, et indique {n} articles correspondent, {m} seraient ajoutés (non lus, pas encore pris). Rien n'est ajouté. L'aperçu ignore Activé, et il juge la règle seule : un article qu'une autre règle prendrait d'abord est quand même compté.

Le formulaire n'a pas de champ pour la priorité de la règle ni pour ses tags ; il garde la priorité enregistrée, et perd les tags (voir Bugs connus).

Le résultat de chaque règle (et de chaque Téléchargement manuel) est écrit dans le tableau Activity de l'onglet Workflows : Workflow RSS: <rule name> (ou RSS: (manual)), Action rss_add, Outcome applied, skipped (détail already in this client) ou failed (avec la raison). Voir Workflows.

Flux

URL : http:// ou https:// seulement (tout le reste : 400). La même URL ne peut pas être ajoutée deux fois (409).
Nom et dossiers : un flux vit à un chemin à la manière de qBittorrent, Folder\Name avec une barre oblique inverse. Les dossiers manquants sont créés. Un nom vide devient l'hôte de l'URL (jamais l'URL entière, qui montrerait la passkey partout où le nom s'affiche), avec (2), (3)… s'il est déjà pris. Un chemin qui est déjà un flux ou un dossier, ou qui se trouverait à l'intérieur d'un flux, est refusé (409). Les dossiers sont visibles par l'API et le shim ; l'onglet montre le chemin complet de chaque flux.
Intervalle : chaque flux a le sien, refresh_secs. Un nouveau flux reçoit [rss] refresh_minutes (30 minutes par défaut) ; le minimum est de 5 minutes, et toute valeur plus petite est relevée à ce minimum. Un flux est à récupérer quand sa dernière récupération est plus ancienne que son intervalle ; un flux jamais récupéré l'est tout de suite.
Limites de récupération : délai de 30 secondes, 5 Mio par flux, le User-Agent du client. Au plus 4 flux sont récupérés en même temps par la tâche de fond ; un flux déjà en cours de récupération n'est pas récupéré deux fois.
Articles gardés : les [rss] max_articles plus récents par flux (200 par défaut, entre 1 et 10 000), fusionnés par guid à chaque récupération. Les plus anciens sont supprimés.
Erreurs : une récupération ratée (réseau, statut HTTP, trop gros, XML illisible, sortie fermée) ne provoque pas d'erreur d'API ; elle est stockée comme dernière erreur du flux et affichée dans État. Les articles déjà stockés restent.
Changer l'URL (Modifier, PATCH ou rss/setFeedURL) fait suivre la nouvelle URL aux règles qui nommaient l'ancienne, et récupère à nouveau le flux au tour suivant.
Supprimer un flux supprime ses articles, pas l'enregistrement de ce qui a été pris : rajouter le flux plus tard ne rajoute pas ces torrents.

Ce qu'est un article. Son identité est <guid> (<id> en Atom), sinon son lien torrent, sinon son lien de page, sinon son titre. Son lien torrent est l'enclosure de type application/x-bittorrent, sinon un magnet dans <link>, sinon toute autre enclosure, sinon un élément magnetURI, sinon <link>. Sa taille est la longueur de l'enclosure, sinon un attribut torznab/newznab size, contentLength ou <size> ; 0 = inconnue. Sa date est pubDate (published / updated en Atom) ; un article sans date reçoit l'heure à laquelle il a été vu pour la première fois. Le lecteur XML saute ce qu'il ne comprend pas (DTD, instructions de traitement, espaces de noms) plutôt que de refuser le flux.

Secrets dans les URL. Les journaux et les messages d'erreur montrent les URL de flux et de torrent masquées : la requête remplacée par ?***, les identifiants retirés, tout segment de chemin de 16 lettres, chiffres, - ou _ ou plus contenant au moins un chiffre remplacé par ***, un magnet réduit à son xt=. L'onglet montre l'URL masquée. L'API native renvoie l'URL en clair (url) et masquée (url_masked) : quiconque a la clé API peut y lire vos passkeys.

Filtres

Une règle ne prend un article que si son titre passe tous les filtres. La casse est ignorée partout.

Doit contenir, sans expressions régulières :

| sépare des alternatives : une seule suffit.
À l'intérieur d'une alternative, les espaces séparent des mots qui doivent tous être dans le titre, dans n'importe quel ordre.
* (n'importe quelle suite de caractères) et ? (un caractère) sont des jokers.
Vide = tous les titres. Une alternative vide (foo|) correspond aussi à tous les titres, comme dans qBittorrent.

show 1080p|show 2160p prend un titre qui contient à la fois show et 1080p, ou à la fois show et 2160p.

Ne doit pas contenir : la même syntaxe ; un article est rejeté si une alternative correspond. Les alternatives vides sont ignorées ici (cam| ne rejette que cam). Il n'y a pas de syntaxe d'exclusion -mot : utilisez Ne doit pas contenir.

Utiliser des expressions régulières : chacun des deux champs est une expression régulière insensible à la casse. Une expression régulière qui ne compile pas est refusée à l'enregistrement de la règle (400), pas ignorée en silence.

Filtre d'épisodes, deux syntaxes :

Celle de qBittorrent : 1x2;8-15;30-; = saison 1, épisode 2, épisodes 8 à 15, et épisode 30 et suivants — la plage ouverte continue dans les saisons suivantes. La saison 0 est refusée ; une plage inversée (15-8) est ignorée.
Plages saison-épisode : S01E01-S01E10;S02E05;S03E01-; — une plage peut traverser les saisons ; ; ou , séparent les entrées.

Les titres sont lus sous la forme S01E05, s1.e5, S01 E05 ou 1x05. Un titre sans numéro d'épisode — un pack de saison, par exemple — ne correspond jamais à une règle qui a un filtre d'épisodes. Un filtre illisible est refusé à l'enregistrement (400, avec les formes attendues dans le message).

Filtre d'épisodes intelligent : une fois que la règle a pris un épisode (clé S01E05, ou la date YYYY-MM-DD d'une émission quotidienne), le même épisode n'est plus repris, sauf si le nouveau titre contient REPACK ou PROPER (toujours autorisés ; il n'y a pas de réglage pour cela). Les épisodes pris sont gardés dans previouslyMatchedEpisodes de la règle.

Ignorer les correspondances suivantes pendant N jours : après que la règle a pris quelque chose, un article daté de moins de N jours après cette correspondance n'est pas pris. 0 = désactivé. La date comparée est celle de l'article, si bien que des articles plus anciens trouvés plus tard ne réveillent pas non plus la règle.

Ordre entre les règles : les règles sont essayées par priority (la plus basse d'abord ; 0 par défaut), puis par nom. La première règle activée qui nomme le flux et correspond à l'article le prend ; les autres ne voient jamais cet article.

Où va un torrent ajouté

La Catégorie de la règle décide, exactement comme pour tout ajout (Catégories & routage) :

une catégorie en mode hoard → le moteur hoard ; toute autre catégorie → le moteur race ;
le dossier est le Dossier d'enregistrement de la règle s'il est renseigné, sinon le chemin de sauvegarde de la catégorie ;
pas de catégorie, ou une catégorie inconnue → le moteur race, et aucun dossier : sauf si la règle a un Dossier d'enregistrement, chaque ajout est refusé avec no save path: category "<name>" is unknown and no savepath was given ("" sans catégorie) (ou, pour un .torrent à fichier unique quand [daemon] create_torrent_folder = true, no save path: give one, or a category that has one) — et un refus est définitif (l'article est enregistré comme pris). Donnez à chaque règle une catégorie qui a un chemin de sauvegarde, ou un dossier d'enregistrement.

Un .torrent passe aussi par [daemon] create_torrent_folder (les torrents à fichier unique dans leur propre dossier), le contrôle d'admission disque de race, la réservation de chemin et la dédup, et déclenche les workflows quand un torrent est ajouté (when a torrent is added). Un magnet passe par la file des magnets et est résolu plus tard, comme tout ajout de magnet. Les tags de la règle (torrentParams.tags, réglés par l'API) sont appliqués ; Ajouter en pause l'ajoute arrêté.

L'ordre de téléchargement (priorités de fichiers, séquentiel, première/dernière pièce) n'est pas un réglage RSS : il se règle sur le torrent après l'ajout, voir Ajouter des torrents & données existantes (Ordre de téléchargement).

Ce que devient un article

flowchart TD
    T["Tour de la tâche de fond : toutes les 30 s, ou tout de suite quand un flux est ajouté ou une règle change"] --> EN{"[rss] enabled ?"}
    EN -- non --> OFF["Rien n'est récupéré, aucune règle ne tourne"]
    EN -- oui --> DUE["Flux à récupérer : jamais récupérés, ou intervalle écoulé ; 4 à la fois"]
    MAN["Rafraîchir, Tout rafraîchir, rss/refreshItem"] --> X
    DUE --> X{"Sortie du moteur du flux ouverte ?"}
    X -- non --> E1["dernière erreur : pas récupéré, la sortie est fermée"]
    X -- oui --> F["Récupération par le tunnel, l'interface ou le proxy de ce moteur : 30 s, 5 Mio"]
    F -- "erreur réseau, erreur HTTP, trop gros, pas un flux" --> E2["dernière erreur renseignée, articles stockés gardés"]
    F -- ok --> M["Fusion par guid, garde les max_articles plus récents"]
    M --> EN2{"[rss] enabled ?"}
    EN2 -- non --> KEEP["Articles stockés, aucune règle ne tourne"]
    EN2 -- oui --> A["Chaque article non lu que rien n'a encore pris, le plus ancien d'abord"]
    DUE -- "après les récupérations, si une règle a changé : tous les flux, sans récupération" --> A
    A --> R{"Première règle activée nommant ce flux qui correspond ?"}
    R -- aucune --> N["Laissé non lu, proposé de nouveau aux passes suivantes"]
    R -- oui --> K{"Lien torrent"}
    K -- magnet --> MQ["File des magnets"]
    K -- "http ou https" --> G["Récupération du .torrent par la sortie du moteur de la règle : 30 s, 10 Mio, doit se lire"]
    K -- "aucun ou autre schéma" --> RF
    G -- "sortie fermée, erreur réseau, pas un torrent" --> TR["échec : reste non lu et non pris, retenté après la prochaine bonne récupération de ce flux"]
    G -- ok --> P["Pipeline d'ajout : la catégorie choisit moteur et dossier, réservation de chemin, dédup, workflows à l'ajout"]
    MQ -- "mis en file" --> OK
    MQ -- "déjà ajouté" --> SK
    MQ -- refusé --> RF
    P -- ajouté --> OK["Pris (added), marqué lu ; Activity : applied"]
    P -- "déjà dans ce client" --> SK["Pris (already), marqué lu ; Activity : skipped"]
    P -- refusé --> RF["Pris (refused: raison), marqué lu ; Activity : failed ; définitif"]

Résultat	Enregistrement « pris » (`taken.outcome`)	Article	Activity	Retenté ?
Ajouté	`added`	marqué lu	`applied`	—
Le torrent est déjà dans ce client	`already`	marqué lu	`skipped`, `already in this client`	—
Refusé par le pipeline d'ajout (pas de chemin de sauvegarde, disque race plein, chemin réservé, pas de lien torrent, un lien impossible à ajouter…)	`refused: <reason>`	marqué lu	`failed`, la raison	Non, jamais par une règle. Téléchargement dans le panneau Articles l'ajoute quand même à la main.
La sortie du moteur est fermée, une erreur réseau, ou la réponse n'est pas un torrent	aucun	reste non lu	`failed`, raison + `; tried again at the next pass`	Oui, après la prochaine récupération réussie de ce flux

Après un résultat added ou already, la Dernière correspondance de la règle est mise à maintenant et, avec le filtre intelligent activé, l'épisode est enregistré. Une récupération réussie fait toujours tourner les règles sur ce flux, même si elle n'a rien apporté de nouveau : c'est ainsi qu'un échec passager obtient sa deuxième chance. Enregistrer ou activer/désactiver une règle fait que le tour suivant de la tâche de fond propose de nouveau aux règles les articles non lus de chaque flux, sans récupération. Une seule passe tourne à la fois, si bien que deux récupérations qui se terminent ensemble ne peuvent pas prendre deux fois le même article.

Téléchargement dans le panneau Articles saute les règles, la vérification « activé » et la vérification « pris » : il ajoute l'article même si une règle l'a pris ou refusé auparavant, puis l'enregistre comme pris par (manual).

Par quelle sortie passe un flux

Le flux d'un tracker porte votre passkey, et le tracker voit l'adresse d'où le flux est récupéré. Un flux est donc récupéré par la sortie du moteur où iront ses torrents :

le moteur de la première règle activée (par priorité, puis par nom) qui nomme le flux — via la catégorie de cette règle — sinon le moteur où va un ajout sans catégorie (race) ;
le tunnel WireGuard, l'interface liée ou le proxy SOCKS5 de ce moteur, tels que [daemon] egress = "engine:<id>" les résoudrait ;
puis l'announce_proxy de ce moteur s'il en a un (la route que prennent ses annonces), sinon, quand la route n'a pas encore de proxy, TYPHON_ANNOUNCE_PROXY s'il est défini ;
un moteur que ce nœud ne fait pas tourner : direct quand le kill switch est désarmé, refusé quand il est armé.

Un lien .torrent est récupéré par la sortie du moteur auquel sa règle ajoute (pour un Téléchargement manuel : le moteur de la catégorie choisie). Un flux partagé par des règles de deux moteurs est récupéré par la sortie de la première règle.

Si le kill switch tient ce moteur hors du réseau, rien n'est récupéré : l'état du flux est bloqué par le kill switch et sa dernière erreur se lit not fetched: the way out of engine <id> is closed (…). La ligne via … de la colonne État et les champs engine / via / blocked de l'API vous disent quel chemin a été utilisé. Détails : VPN & sortie réseau, WireGuard géré.

Configuration

[rss] est facultative et ne figure pas dans le default.toml livré : sans elle, les valeurs par défaut ci-dessous s'appliquent. Ajoutez-la au fichier de configuration et redémarrez Hydranos.

[rss]
enabled = true          # false : la tâche de fond ne récupère rien et les règles n'ajoutent rien
max_articles = 200      # articles gardés par flux, les plus récents (1 à 10000)
refresh_minutes = 30    # intervalle donné à un NOUVEAU flux ; minimum 5

Clé	Défaut	Effet
`enabled`	`true`	`false` arrête la tâche de fond et les règles. Les flux, articles et règles sont gardés. Rafraîchir et Téléchargement manuels fonctionnent toujours (voir plus bas).
`max_articles`	`200`	Articles gardés par flux après chaque récupération, les plus récents d'abord. Borné à 1–10 000.
`refresh_minutes`	`30`	L'intervalle des flux créés ensuite (défaut de l'interface, `POST /api/rss/feeds` sans `refresh_secs`, `rss/addFeed` sans `refreshInterval`). Les flux existants gardent leur propre `refresh_secs`. En dessous de 5 → 5.

Non configurables : le tour de 30 secondes de la tâche de fond, 4 récupérations en parallèle, le délai de 30 secondes, 5 Mio par flux, 10 Mio par .torrent. Les préférences RSS de qBittorrent (rss_refresh_interval, rss_processing_enabled, rss_auto_downloading_enabled, rss_smart_episode_filters, …) ne font pas partie de app/preferences du shim et ne sont pas lues par app/setPreferences : [rss] est le seul interrupteur.

API

Toutes les routes demandent la clé API (en-tête X-Api-Key ou paramètre apikey) ou une session connectée, comme le reste de l'API (Sécurité & accès).

Routes natives

Route	Méthode	Ce qu'elle fait
`/api/rss`	GET	Tout ce que montre l'onglet : `enabled`, `max_articles`, `default_refresh_secs`, `min_refresh_secs`, `feeds`, `folders`, `rules`.
`/api/rss/feeds`	GET, POST	Lister les flux ; en ajouter un avec `{"url","path"` (ou `"name"`)`,"refresh_secs"}` → 201. Un flux : `id`, `uid`, `path`, `name`, `url`, `url_masked`, `title`, `refresh_secs`, `last_refresh`, `next_refresh`, `last_error`, `loading`, `articles`, `unread`, `engine`, `via`, `blocked`.
`/api/rss/feeds/:id`	PATCH, DELETE	Changer `path` (ou `name`), `url`, `refresh_secs` ; supprimer le flux et ses articles.
`/api/rss/feeds/:id/refresh`	POST	Récupérer maintenant ; répond une fois terminé, avec le flux (`last_error` dit comment cela s'est passé).
`/api/rss/refresh`	POST	Récupérer chaque flux en arrière-plan : 202 `{"refreshing": n}`.
`/api/rss/feeds/:id/articles`	GET	Les plus récents d'abord (`?unread=1` pour les non lus seulement) : `guid`, `title`, `torrent_url`, `link`, `description`, `author`, `category`, `date`, `size`, `read`, `taken` (`{"rule","at","info_hash","outcome"}` ou null).
`/api/rss/feeds/:id/read`	POST	`{"guid"}` marque un article comme lu, `{}` tous.
`/api/rss/feeds/:id/download`	POST	Ajouter un article à la main : `{"guid","category","save_path","paused"}` → `{"info_hash","already"}`. 400 refusé par l'ajout (raison donnée), 502 le `.torrent` n'a pas pu être récupéré.
`/api/rss/folders`	POST	`{"path"}` → 201.
`/api/rss/rules`	GET	Toutes les règles : le document de qBittorrent plus `name`, dans l'ordre priorité puis nom.
`/api/rss/rules/:name`	PUT, DELETE	Créer ou remplacer (corps = le document de règle) ; supprimer.
`/api/rss/rules/:name/rename`	POST	`{"name"}` (ou `new_name`). 409 si déjà pris.
`/api/rss/rules/:name/matching`	GET	Ce que prendrait une règle enregistrée : `{"count","would_add","feeds":[{"id","path","name","articles"}]}`. Rien n'est ajouté.
`/api/rss/preview`	POST	La même chose pour un brouillon (corps = un document de règle).

Les erreurs sont {"error": "…"} avec 400 (mauvaise valeur), 404 (flux, dossier ou règle inconnus), 409 (conflit) ou 500 (store).

Le document de règle

Le document est celui de qBittorrent (rss/setRule), si bien qu'une règle exportée de qBittorrent peut être envoyée telle quelle. Champs gardés et renvoyés : enabled (true par défaut), priority (0 par défaut, la plus basse d'abord), useRegex, mustContain, mustNotContain, episodeFilter, affectedFeeds (les URL des flux), ignoreDays, lastMatch (date RFC 2822), smartFilter, previouslyMatchedEpisodes, et les options d'ajout dans les deux écritures de qBittorrent : celle de la 4.x au premier niveau, assignedCategory, savePath, addPaused, et celle de la 4.6+/5.x, torrentParams {category, save_path, tags, stopped (ou paused)}. Les deux écritures sont renvoyées ; torrentParams l'emporte quand les deux sont données.

Un champ texte, booléen ou liste du mauvais type (enabled, useRegex, smartFilter, mustContain, mustNotContain, episodeFilter, affectedFeeds, previouslyMatchedEpisodes, assignedCategory, savePath) est refusé (400). priority, ignoreDays, lastMatch, addPaused et les champs de torrentParams du mauvais type sont lus comme leur valeur par défaut (0 / non renseigné), sans erreur.
Un enregistrement sans lastMatch ni previouslyMatchedEpisodes garde les valeurs stockées, si bien qu'un éditeur qui ne les montre pas ne remet pas à zéro ignoreDays et le filtre intelligent.
Tout autre champ qBittorrent n'est pas gardé : torrentContentLayout est renvoyé comme null, torrentParams.skip_checking comme false, et les autres options de torrentParams (disposition du contenu, gestion automatique, limites…) sont abandonnées.

# Ajouter un flux
curl -s -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"url":"https://tracker.example.org/rss?passkey=YOUR_PASSKEY","path":"TV\\Tracker","refresh_secs":900}' \
  http://localhost:8199/api/rss/feeds

# Créer une règle avec des tags (le formulaire web ne peut pas régler les tags)
curl -s -X PUT -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"enabled":true,"mustContain":"show 1080p","mustNotContain":"cam|hdts",
       "episodeFilter":"S02E01-","smartFilter":true,
       "affectedFeeds":["https://tracker.example.org/rss?passkey=YOUR_PASSKEY"],
       "torrentParams":{"category":"tv","tags":["rss"]}}' \
  http://localhost:8199/api/rss/rules/Show%201080p

Shim qBittorrent (`/api/v2/rss/*`)

Ces 13 routes de l'API RSS de qBittorrent existent, avec les mêmes paramètres (chaîne de requête ou corps de formulaire) :

Route	Paramètres	Remarques
`rss/addFolder`	`path`
`rss/addFeed`	`url`, `path`, `refreshInterval`	`refreshInterval` en secondes ; minimum 300.
`rss/setFeedURL`	`path`, `url`	Les règles suivent la nouvelle URL.
`rss/removeItem`	`path`	Un dossier est supprimé avec tout ce qu'il contient.
`rss/moveItem`	`itemPath`, `destPath`
`rss/refreshItem`	`itemPath`	Un flux, ou chaque flux sous un dossier ; en arrière-plan.
`rss/markAsRead`	`itemPath`, `articleId`	Sans `articleId` : tout ce qui est sous le chemin.
`rss/items`	`withData`	L'arborescence des dossiers ; pour chaque flux `uid`, `url`, et avec `withData=true` : `title`, `lastBuildDate`, `isLoading`, `hasError`, `refreshInterval`, `articles` (`id`, `date`, `title`, `author`, `category`, `description`, `torrentURL`, `link`, `isRead`).
`rss/setRule`	`ruleName`, `ruleDef` (JSON)
`rss/renameRule`	`ruleName`, `newRuleName`
`rss/removeRule`	`ruleName`
`rss/rules`	—	Les règles, indexées par nom.
`rss/matchingArticles`	`ruleName`	`{"<feed name>": [titles]}` ; `{}` pour une règle inconnue.

Les écritures sont en POST ; items, rules et matchingArticles répondent à toute méthode. Un paramètre manquant → 400 Missing parameter: X ; une valeur mal formée (mauvaise URL, ruleDef qui n'est pas du JSON, mauvaise regex) → 400 ; tout autre refus → 409 avec la raison en texte brut. Détails du shim : Shim qBittorrent & automatisation.

curl -s -H "X-Api-Key: YOUR_API_KEY" http://localhost:8199/api/v2/rss/setRule \
  --data-urlencode 'ruleName=Show 1080p' \
  --data-urlencode 'ruleDef={"enabled":true,"mustContain":"show 1080p","affectedFeeds":["https://tracker.example.org/rss?passkey=YOUR_PASSKEY"],"assignedCategory":"tv"}'

Bugs connus et limites en 4.4

Bug connu en 4.4 : enregistrer une règle depuis le formulaire web semble ne changer que ce que montre le formulaire — cela efface les tags de la règle (torrentParams.tags, réglés par l'API ou un client qBittorrent), parce que le formulaire n'envoie jamais torrentParams — réglez les tags avec PUT /api/rss/rules/:name ou rss/setRule, et ne modifiez plus ces règles dans le formulaire ensuite (la case Activé du tableau des règles est sans danger : elle renvoie le document entier).

Bug connu en 4.4 : [rss] enabled = false et son bandeau (rien n'est récupéré ni ajouté) ressemblent à un arrêt complet — ils n'arrêtent que la tâche de fond et les règles : Rafraîchir / Tout rafraîchir (et POST /api/rss/feeds/:id/refresh, /api/rss/refresh, rss/refreshItem) récupèrent toujours le flux, et Téléchargement (POST /api/rss/feeds/:id/download) ajoute toujours — supprimez les flux si rien du tout ne doit atteindre le tracker.

Non implémenté en 4.4 : le formulaire de règle n'a pas de champ priorité ni tags, et le Téléchargement du panneau Articles n'a ni chemin de sauvegarde ni option de pause — utilisez l'API (priority et torrentParams.tags dans le document de règle ; save_path et paused sur /api/rss/feeds/:id/download).

Non implémenté en 4.4 : le RSS dans le serveur MCP et dans l'import qBittorrent — aucun outil MCP ne lit ni ne modifie les flux ou les règles (Serveur MCP), et l'assistant d'import apporte les torrents, pas les flux ni les règles de qBittorrent (Migrer depuis qBittorrent) — recréez-les : rss/setRule accepte le JSON de règle de qBittorrent tel quel.

Accepté mais ignoré en 4.4 : les préférences RSS de qBittorrent (rss_refresh_interval, rss_processing_enabled, rss_auto_downloading_enabled, rss_smart_episode_filters, …) et les champs de règle torrentContentLayout, skip_checking et les autres options de torrentParams — ils ne sont pas stockés — utilisez [rss] et les champs listés dans Le document de règle.

Également voulu en 4.4 :

[rss] ne figure pas dans le default.toml livré ; elle n'apparaît qu'une fois que vous l'ajoutez.
Un refus du pipeline d'ajout (pas de chemin de sauvegarde, disque race plein…) est définitif pour les règles ; rajoutez un tel article avec Téléchargement.
REPACK / PROPER passent toujours le filtre intelligent ; les clés d'épisode sont les formes fixes ci-dessus (pas de motifs d'épisode personnalisés).
Un pack de saison (pas de numéro d'épisode dans le titre) ne correspond jamais à une règle avec un filtre d'épisodes.
Certaines erreurs de l'onglet RSS (Rafraîchir, Tout rafraîchir, Supprimer, Tout marquer comme lu, la case Activé d'une règle) et les confirmations de suppression utilisent les boîtes alert() / confirm() du navigateur, contrairement au reste de l'interface ; les formulaires de flux et de règle, Aperçu et Téléchargement affichent leurs erreurs dans la page.

Pages liées

Ajouter des torrents & données existantes (le pipeline d'ajout, l'ordre de téléchargement) · Catégories & routage · Workflows (Activity) · VPN & sortie réseau · WireGuard géré · Shim qBittorrent & automatisation · API REST · Config : démon, auth & global · Limites connues de la 4.4

Hydranos wiki — documents v4.4.1. · 🇬🇧 Home · 🇫🇷 Accueil · Changelog · Report an issue

Hydranos 4.4 · 🇬🇧

Start

Install

Use

Integrate

Network & machines

Operate

Reference

Hydranos 4.4 · 🇫🇷

Démarrer

Installer

Utiliser

Intégrer

Réseau & machines

Exploiter

Référence

Repository · Releases · Changelog

RSS and Automatic Downloads FR

RSS et téléchargements automatiques

Ce que cela fait

L'onglet RSS

Flux

Filtres

Où va un torrent ajouté

Ce que devient un article

Par quelle sortie passe un flux

Configuration

API

Routes natives

Le document de règle

Shim qBittorrent (/api/v2/rss/*)

Bugs connus et limites en 4.4

Pages liées

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Shim qBittorrent (`/api/v2/rss/*`)