Bonjour, J'utilise beaucoup de seedbox différentes (toutes rutorrent sur dédié) Mais je viens d'en installer une sur un serveur Online, et pour la première je constate que lorsque je rapatrie mes fichiers directement depuis l'interface rtorrent (en double cliquant sur le fichier) le film arrive corrompu. Mais pas de soucis via FTP Or c'est le seul serveur avec qui j'ai ce problème, comment cela peut s'expliquer ? Quand je télécharger un fichier d'une autre seedbox de la même manière en même temps, aucun soucis. C'est vraiment cette seedbox

Après quelques essais (j'ai fait télécharger chez d'autres personnes), le film se coupe exactement au même moment que chez moi (44 minutes pour le film commun). Cela peut venir d'une configuration ratée ou du matériel ?? Je compte réinstaller du coup A noter pas de soucis pour les fichiers plus léger (non HD)

Pour telecharger des gros fichiers en http il existe des logiciel qui evitent les pertes de données.. tu a essayé de ce coté là ? Je n'est aucun nom en téte dsl.. ;/ Edit : Flashget si ma memoire est bonne, etait un bon logiciel a l'epoque ^^

Non je n'ai pas essayé, mais ces logiciels servent si la connexion domestique décrochent, là c'est clairement le serveur. Jamais eu de soucis avant, surtout que ça décroche au même moment vu que les films sont corrompus à partir de la même minute. Je parierais plus sur un soucis logiciel compte tenu de ça Mais ça me dépasse un peu Merci de la réponse

Bonsoir, j'imagine, il s'agit d'un manque dans la conf(ig) de Nginx. À l'occasion, il m'est déjà arrivé de rencontrer ce problème. Dont j'ignore la solution... Comme évoqué, le FTP à palier au problème. Le télécharger de nouveau le corrigé seule parfois. La réinstallation sera inutile, il faut parvenir à trouver ce manque...

Wagner wrote: Bonsoir, j'imagine, il s'agit d'un manque dans la conf(ig) de Nginx. À l'occasion, il m'est déjà arrivé de rencontrer ce problème. Dont j'ignore la solution... Comme évoqué, le FTP à palier au problème. Le télécharger de nouveau le corrigé seule parfois. La réinstallation sera inutile, il faut parvenir à trouver ce manque... La réinstallation sera inutile ? Je repartirais de zéro du coup logiquement je referais pas la même erreur, quoique j'ai quasiment rien personnalisé dans le tutoriel de Magic (première fois que je l'utilise). Mais je suppose que si ça venait du tutoriel je serais pas le seul. Télécharger de nouveau ? J'ai pas compris, tu parle de le re-rapatrier le fichier Un troisième pote à télécharger un autre film, qui lui aussi s'arrête à 44 minutes. Encore plus étrange le film fait 5,5 gigas, et dans la fenêtre de téléchargement Firefox il fait 11 gigas ! Et dans le Finder (sous mac donc) il passe à 6,77 gigas. !!

Oui, c'est étrange... Bref, même avec une personnalisation, elle me semble toujours inutile. D'autant plus, si elle est minimal. Il devrait suffir de corriger la conf(ig) de Nginx. Au pire, il est tout à fait possible de reprendre de zero (la conf(ig)). Nginx le comprendra sans problème. Une réinstallation, c'est conseilllé (voir recommandé) lorsqu'il y a (au moins) un vrai problème. Là, pour moi, ce n'est le cas. Mails wrote: Télécharger de nouveau ? J'ai pas compris, tu parle de le re-rapatrier le fichier Oui, c'est bien ça.

J'ai tenté de rétélarger beaucoup beaucoup de fois, malheuresement ça n'a pas réglé le problème. Je veux bien que tu m'aides à reprendre ma config, c'est quel fichier ? (chemin)

Celui de ruTorrent, tout simplement. Normalement, c'est : nano /etc/nginx/sites-enabled/rutorrent.conf Cette commande permet de tester la conf(ig) de Nginx : nginx -t ## ou ## service nginx configtest Elle vérifie la syntaxe et retournera une erreur si tel est cas. service nginx restart Bien entendu, il faudra redémarrer Nginx. Ainsi, la nouvelle conf(ig) sera appliquée.

Le test ne nginx est positif pour la config de rutorrent : server { listen 80; server_name ndd.tk; charset utf-8; index index.html index.php; client_max_body_size 10M; #ssl_certificate /etc/nginx/ssl/server.crt; #ssl_certificate_key /etc/nginx/ssl/server.key; access_log /var/log/nginx/rutorrent-access.log combined; error_log /var/log/nginx/rutorrent-error.log error; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } auth_basic "seedbox"; auth_basic_user_file "/etc/nginx/passwd/rutorrent_passwd"; location = /favicon.ico { access_log off; log_not_found off; } ## début config rutorrent ## location ^~ /rutorrent { root /var/www; include /etc/nginx/conf.d/php; include /etc/nginx/conf.d/cache; location ~ /\.svn { deny all; } location ~ /\.ht { deny all; } } location ^~ /rutorrent/conf/ { deny all; } location ^~ /rutorrent/share/ { deny all; } location /commun { include scgi_params; scgi_pass 127.0.0.1:5001; auth_basic "seedbox"; auth_basic_user_file "/etc/nginx/passwd/rutorrent_passwd_commun"; } ## début config seedbox-manager ## location ^~ / { root /var/www/seedbox-manager/public; include /etc/nginx/conf.d/php; include /etc/nginx/conf.d/cache; } ## fin config rutorrent ## }

Bien, le problème est touours présent, non ? Alors, il y a bien un manque... Comme c'est un flux http, avec l'une (voir plusieurs) des directives du module ngx_http_core_module , on devrait finir par trouver une solution.

[Résolu] Le download en HTTP est vicié sur ma seedbox : Page 2

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Le download en HTTP est vicié sur ma seedbox

Wagner

Dans ce cas, je comprends. Toutefois, je me dis, j'aurais peut-être du insister un peu plus... Les chances d'une mauvaise piste étaient plutôt bien faible (voir nul).

Bref, au fil du temps, j'en suis venu également à penser la même chose, c'est lié à ruTorrent. En fait, je songe principalement au PHP. Ainsi, avec les messages d'erreurs (cf mon message précédent), j'imagine la solution devrait se trouver avec le module http_fastcgi ou le module http_upstream... J'espère que l'on trouvera une solution. Ce serait préférable. D'autant, ce problème se produit aussi avec le (plugin) FileManager.

Juste pour m'en assurer. Je regarderai si via ce listing, j'obtiens le même résultat. Ce fut bien le cas.

Guère de progrès... néanmoins grâce à ceci :

fastcgi_ignore_client_abort on;

Les messages d'erreurs ont (un peu) changé :

writev() failed (104: Connection reset by peer) while sending to client
writev() failed (32: Broken pipe) while sending to client

« Page précédente