S'il vous plaît fournir les informations suivantes
v4.1.6 officiel, Win-32
### Si sur Linux, libtorrent et version Qt
-
Certains .torrents fournissent des URL pour le leeching.
Le problème est le suivant : « Supprimer la graine Web » ne fonctionne pas dans les « Sources HTTP » de ce torrent.
L'URL disparaît de l'interface utilisateur et du fichier .fastresume, mais n'est pas supprimée du fichier .torrent. Donc qbt essaie de télécharger à nouveau à partir de cette URL après le redémarrage de qbt.
Contexte : Si l'URL du .torrent n'est pas accessible, ces messages inondent le LOG, jusqu'à deux fois par seconde. Si LOG est activé dans l'interface utilisateur (pour l'affichage), cela finira par bloquer qbt pendant 2 minutes sur mon système.
Supprimez l'URL du fichier .torrent.
Désolé, je ne peux actuellement pas fournir de fichier .torrent.
une. Veuillez rétroporter vers 4.1.x, si possible.
b. Impossible de trouver un autre problème comme celui-ci sur github, parcourant 13 pages. Désolé, si c'est un dupe.
Je le confirme sur libtorrent RC_1_2 bd0d01153641ffb1913f531b68c860b90efe0735
Et aussi RC_1_1 84f10d05caff0d20213280951752797d166e1759
@arvidn
Je soupçonne que c'est un bogue dans libtorrent.
Nous utilisons actuellement read_resume_data()
pour lire dans le fastresume et il semble que le fastresume ne soit pas prioritaire ici, c'est-à-dire que s'il n'y a pas url-list
champ
il n'y a pas de champ de liste d'URL dans fastresume, alors il ne devrait y avoir aucune graine Web pour le torrent.
C'est un comportement attendu, OMI.
Sera corrigé dans la prochaine version 4.2.0. (RP #11104)
Commentaire le plus utile
Je le confirme sur libtorrent RC_1_2 bd0d01153641ffb1913f531b68c860b90efe0735
Et aussi RC_1_1 84f10d05caff0d20213280951752797d166e1759
@arvidn
Je soupçonne que c'est un bogue dans libtorrent.
Nous utilisons actuellement
read_resume_data()
pour lire dans le fastresume et il semble que le fastresume ne soit pas prioritaire ici, c'est-à-dire que s'il n'y a pasurl-list
champ