À défaut de recourir à celui de Ex_rat, pour lequel un ménage a été fait récemment, me laissant sans seedbox-manager, très utile pour moi, j'ai installé celui de ratxabox qui marche très bien à date sur Debian 8 64bits de OneProvider.
Seedbox-manager y est, fonctionnel comme le reste du script. Un gros merci à l'auteur de l'original et à ratxabox et ses collaborateurs pour l'adaptation.

xavier

Merci Xavier pour ton retour.
Je passerai à Debian 9

@xavier utilise tu ton nom de domaine octo.io ? J'aimerai te le racheter ! Merci, Guillaume

citizenz7 hum... passage en Debian 9... et tout fonctionne.

Seedbox-manager est fonctionnel mais lorsque j'efface un torrent et supprime les données, aucune mise à jour n'est faite pour l'espace disque. Le % ne varie pas et je dois supprimer le torrent "effacé", en recourant à FileZilla. Ça minimise donc l'utilité manager, lequel contient toutefois beaucoup d'informations utiles du compte et de l'accès FTP et SFTP. Il permet aussi de redémarrer rtorrent. Suis-je le seul à expérimenter cette lacune pour l'espace disque ? Merci de votre feedback.

dofin Hello, Ton problème n'a aucun rapport avec "seedbox-manager" mais plutôt avec ruTorrent.

Normal que le % d'espace disque ne change pas si ruTorrent n'arrive pas à supprimer les données du torrent. ^^

Bien oui, je comprends ta remarque Micdu70, mais en quoi rutorrent est-il la cause ? Une faille dans le script ? Je ne l'ai modifié aucunement modifié.
Avec Ex_rat, seedbox-manager, tenait compte de l'espace disque si on supprimait un torrent de la liste, en indiquant de supprimer les données.

Bonjour, j'ai contacté le service technique de OneProvider pour le sujet suivant: vitesse lente et pas constante.
J'utilise IDM pour télécharger les gros fichiers. La vitesse est correcte, au début, mais en moins de 2 minutes, elle passe de 450 MBit/s à un très bas 99 MBits/s. Avec mon autre serveur de PulseMedia, cela n'arrive pas; la vitesse atteint la limite de ma connection à la maison, et demeure constante !

Si j'utilise FileZilla, la vitesse atteint le deux tiers de ma capacité mais demeure constante.

Ma question est la suivante, le service technique m'a envoyé les directives qui suivent. Que dois-je en penser ? Et qu'est-ce qui est recherché ?

"Please boot your server in RESCUE MODE and provide the output of an IPERF, speedtest-cli and ethtool tests:
1.
IPERF3
o apt-get -y update #update the rescue os
o apt-get -y install iperf3 #install iperf3
o iperf3 -c ping.online.net -R

2.
speedtest-cli:
o wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py #download

o chmod +x speedtest-cli #allows the file to be executed

o ./speedtest-cli #runs the test

3.
Ethtool:
o ethtool eth0

4. MTR:
   • the MTR in both directions (from the host where you reported the issue to a remote server and vice versa)
   • the tests must be done in rescue mode
   • 100 packets have to be sent for each test (option -c 100)
   o example : mtr -rw -c 100 IP_HERE

Voilà ! Quelqu'un peut-il me faire une suggestion ou me renseigner davantage ? Merci à l'avance.

Il s'agit de faire des tests de vitesse avec un OS certifié propre (en mode rescue)

Pas une seule réponse, alors, je continue à chercher. Ce serait peut-être un problème de routing. J'ai fait un traceroute et envoyé les résultats à Oneprovider. Ça donne cela:
Détermination de l’itinéraire vers 163-172-42-240.rev.poneytelecom.eu [163.172.42.240]
avec un maximum de 30 sauts :

1 <1 ms <1 ms <1 ms EMG2926 [192.168.0.1]
2 11 ms 9 ms 13 ms modemcable001.63-178-173.mc.videotron.ca [173.178.63.1]
3 10 ms 19 ms 8 ms 10.170.154.30
4 20 ms 18 ms 14 ms 216.113.122.210
5 18 ms 18 ms 26 ms hu0-3-0-2.ccr21.ymq01.atlas.cogentco.com [38.104.226.225]
6 96 ms 95 ms 98 ms be3042.ccr21.lpl01.atlas.cogentco.com [154.54.44.161]
7 96 ms 100 ms 88 ms be2391.ccr51.lhr01.atlas.cogentco.com [154.54.39.149]
8 103 ms 103 ms 106 ms be3684.ccr41.par01.atlas.cogentco.com [154.54.60.169]
9 95 ms 108 ms 102 ms be3183.ccr31.par04.atlas.cogentco.com [154.54.38.66]
10 99 ms 97 ms 101 ms be3750.rcr21.b022890-0.par04.atlas.cogentco.com [154.54.60.202]
11 97 ms 104 ms 95 ms online.demarc.cogentco.com [149.6.164.42]
12 103 ms 105 ms 101 ms pni-th2-a9k1.th2.poneytelecom.eu [195.154.1.37]
13 106 ms 111 ms 98 ms 195.154.2.195
14 103 ms 106 ms 105 ms 163-172-42-240.rev.poneytelecom.eu [163.172.42.240]

Itinéraire déterminé.

On voit que dès la ligne 5, le temps de réponse est à 26ms, puis cela se gâte encore plus, passant à 98, 88 et même 106ms. J'appellerais cela un réel problème. À suivre ! Oneprovider va refaire des tests de vitesse et j'ai demandé un re-routing pour régler le problème. Si cela ne se règle pas, je n'aurai pas le choix de résilier mon petit serveur, obtenu à la moitié du prix habituel. Dommage.

Bonsoir,

Peu être une piste
https://lafibre.info/tutoriels-linux/tcp-offload-engine/

Oh merci ! Je vais l'essayer car oneprovider vient de m'écrire que "Note that this is a budget server and therefore we can't guarantee minimum speeds, especially on international networks."
J'ai l'impression que pour eux, une vitesse de 99 Mbps en download, est acceptable alors même que ma vitesse de résidence est de plus de 450 Mbps !
Tout pour que j'upgrade, quoi.
Merci beaucoup pour ton aide.

Avec cette réponse, je pense qu'il serait mieux de penser à choisir un autre serveur:

"Note that our budget models like this one are located in a shared network without premium connectivity, as a result international traffic can be congested depending on the path. Anyhow 100-400Mbps is a really acceptable result considering the long distance between our network and your location."