Bonsoir,

Depuis un certain temps - et sans avoir modifié les paramètres de JDL - j'observe que le téléchargement de listes de fichiers sur le même serveur ne se fait pas bien. Certains fichiers sont marqués d'une croix rouge. Si je clique droit sur le nom et que je réinitialise, le fichier se charge généralement sans problème. Souvent le premier fichier se charge, puis 2 ou 3 ratent et puis le 4e marche , etc. Cela se passe sur deux serveurs différents: Filesonic et Filepost.

Ne serait-ce pas que JDL laisse trop peu de temps au serveur pour passer d'un fichier au suivant ? Dans ce cas comment augmenter la temporisation lors de l'envoi de la liste ?

Merci.

Veuillez lire "Problèmes de téléchargement?" dans la F.A.Q..

"Veuillez lire "Problèmes de téléchargement?"

c'est la première chose que j'ai fait mais je ne m'y retrouve pas car cela part dans tous les sens. Faut être spécialiste pour comprendre de quoi on parle parfois.

Est-ce que vous pouvez expliquer ce que vous ne comprenez pas? Les mots ou les instructions? Quels points?

Merci.

Par exemple:

2) Permettre java.exe, javaw.exe dans votre pare-feu et logiciel antivirus.
Comprends pas de quoi on parle. Je n'ai pas de pare-feu et j'utilise AVG free depuis des années sans problèmes. Et je ne vois pas comment permettre ces exécutables dans AVG. Cette application est surtout accessible par interface graphique/icones.

3) Désactiver le port 80/web/http-scan dans votre logiciel antivirus.
Il n'y a pas d'accès de ce genre dans AVG free

5) Quitter ou réduire le nombre de connexions dans votre client BitTorrent.
Je n'utilise pas bittorrent

6) Désinstaller votre logiciel antipub : Ad Muncher et Adblock Plus peuvent bloquer jD.
Adblock est actif sans problème depuis des années avec JDL. De plus cette extension ne fonctionne qu'en Firefox. Or ici on est dans une application Java sans même que FireFox soit ouvert. Comprends pas ce que cela vient faire.

Si cela ne fonctionne pas, donnez un journal détaillé et complet s'il vous plaît.
Aucune idée d'où trouver ce journal dans W7 ultimate.

Re-merci.

2) Opérer sans pare-feu est dangereux. J'espère que vous avez un pare-feu dans votre routeur. Ce n'est pas parce que quelque chose marche pendent des années que ce truc est devenu infaillible.

3) Ça exclut déjà un des causes possibles de votre problème.

5) idem

6) Voir point 2). Récemment il y eu plusieurs problèmes concernant jD avec ces antipubs. Si vous êtes sûr qu'ils ne posent aucun danger, je vous crois sans problème.

Ma conclusion : AVG est probablement la cause du problème.

Mon routeur est équipé d'un pare-feu, NAT, et tout et tout. Effectivement un fonctionnement durant plusieurs années n'est pas un gage d'avenir puisque les techniques d'attaque évoluent.

Je vais essayer de télécharger en débranchant AVG qui fonctionne sans doute aussi sur les téléchargements. Je vous dirai quoi si cela change. Merci.

Apparemment bien vu pour AVG. Je viens de lancer le chargement de 36 fichiers par groupe de 20 simultanés avec 2 connexions sans coincement ni réinitialisation, dont 15 sur le même serveur. Débit total 3MB/s minimum.

Où est la solution car débrancher AVG va un jour déboucher sur un oubli catastrophique ? Comme c'est une version free je n'ai pas de support sur AVG. Je vais quand même regarder sa configuration en détail.

Je viens de voir qu'il y a moyen de configurer des exceptions sur l'anti-virus (bouclier résident) en désignant un chemin vers le répertoire de dépôt des fichiers téléchargés par JDL. Mais je me demande où le contrôle de AVG a lieu, dans ce répertoire ou directement avant d'y déposer les fichiers ? Je vais essayer et je vous dirai si cela marche. J'espère que AVG détectera les fichiers foireux lorsque je voudrai les changer de place. De toute manière il ne détecte pas les fichiers à problèmes qui sont zippés mais lorsqu'ils sont décompressés. Donc cela ne devrait pas changer grand chose.

Installer un logiciel sans savoir ce qu'il fait ou comment il marche est un risque, surtout quand ce logiciel interfère avec votre trafic Internet.

Télécharger des fichiers avec jD ne pose aucun risque, parce que jD ne contient aucun code ou script pour exécuter des fichiers ou ouvrir des fichiers avec des applications dangereuses.

Installer un logiciel sans savoir ce qu'il fait ou comment il marche est un risque, surtout quand ce logiciel interfère avec votre trafic Internet.
Ce n'est pas tout à fait le cas puisque par défaut l'AV était trop restrictif. C'est l'inverse qui serait dangereux. Et AVG n'exécute pas de fichiers, il ne fait que vérifier des signatures et quand il en trouve il met les fichiers en quarantaine en identifiant la signature trouvée. Donc pas trop de craintes d'autant qu'il est mis à jour continuellement mais il y a toujours des signatures qui manquent.

La raison du coincement ici, ce n'est pas que AVG exécute éventuellement du code malicieux téléchargé mais que le temps qu'il prend pour vérifier les signatures est sans doute la cause d'une temporisation défectueuse dans le téléchargement. Je viens de vérifier qu'il n'y a plus de problèmes quand je retire le contrôle durant le téléchargement sur le répertoire utilisé par défaut en JDL. Il me reste à vérifier que les codes dangereux qui seraient provisoirement déposés dans ce répertoire soient détectés au moment où je les transfère ailleurs ou que j'ouvre les fichiers zippés. C'est facile à voir en chargeant un keygen.

Originally Posted by ON5MJ

j'ouvre les fichiers zippés

Ouvrir un archive n'est pas dangereux du tout, si vous utilisez un outil d'extraction connu.

Si vous voulez chercher des virus inexistants, autre que votre virus principal, c'est là, pendent l'ouverture d'un fichier dans un logiciel dangereux comme M$ Office ou Flash, ou l'exécution d'un programme d'un site suspect, qu'il faut être attentive.

La source principale des logiciels malveillants est souvent un site (et oui ça peut etre un site que vous ne soupçonnez pas) ou vous exécutez des scripts. Des extensions (comme les barres d'outils par exemple) dans votre navigateur peuvent être dangereuses aussi parce-qu'ils surveillent votre comportement sur le web.

Ne vous inquiétez pas, je n'installe aucune barre d'outils dans mon navigateur. J'essaie toujours d'avoir l'interface la plus simple possible. De toute façon il n'est pas question ici de navigateur mais de JDL.

C'est quoi ce message dans votre post ?

According to Official jD Supporter raztoki this service was delivered to you by a "total ass".

Est-ce que le problème est résolu?

A propos de ma signature; c'est écrit en Anglais. Ne vous inquiétez pas.

Pour la signature c'est la présence de "ass" qui m'étonnait puisque je comprends ce mot. L'anglais est la langue vernaculaire chez moi avant le français.

Le problème est partiellement résolu mais revient périodiquement mais moins souvent.

Il m'étonne que se sont primordialement les francophones qui se posent des questions concernant ma signature. Selon Isandar ça veut dire

Si j'étais Raztoki, si on jouait au Tarot et que j'avais pris le risque de parler avec peu d'atouts dans ma manche, j'utiliserais mon excuse au bon moment pour pouvoir prendre l'ass à la fin

Et il est content... (j'avoue, j'ai ri )

Le problème est revenu totalement. Il suffit bien sûr de réinitialiser les fichiers.

N'y a-t-il pas moyen de mettre une temporisation entre les appels de plusieurs fichiers sur le même serveur ? Je pense que c'est le serveur qui ne suit pas, les requêtes arrivent trop vite.

Veuillez relire mon message #2 ou diminuez le nombre de téléchargements simultanés.

Je vais commencer par diminuer le nombre de fichiers en parallèle à 10 ou même 5 mais 20 fonctionnait avant. Subitement c'est fini. Une observation quand même: cela ne se passe pas sur des serveurs différents mais uniquement si je charge de multiples fichiers sur le même serveur, ce qui me laisse à penser que c'est le serveur qui ne suit pas parce que les requêtes arrivent trop vite chez lui.

C'est possible. Maintenant vous connaissez la solution.

Non, je ne connais pas la solution. Quand je dis "c'est fini" cela veut dire que c'est fini de charger 20 fichiers en parallèle comme avant. Je viens de tester avec 5 cela n'allait pas fort mieux, je vais tester avec 3. L'ennui c'est que sur un même serveur certains fichiers sont chargés à 1,5 MB/s et d'autres à 20 KB/s. Là je ne comprends pas trop bien.

Cet hébergeur a des serveurs rapides et des serveurs moins rapides ou surchargés.

Mais on ne choisit pas son serveur lors de l'envoi.

Pour l'instant j'ai mis 2 connexions et 5 fichiers en parallèle. Cela fonctionne à peu près bien sur FilePost. Un seul fichier qu'il a fallu réinitialiser. J'en ai (dans la même série .RAR de 32 fichiers) 3 à plus de 900 KB/s et 2 à 50 KB/s.

A noter que si je monte le nombre de fichiers en parallèle progressivement pendant le download il n'y a pas de problème de réinitialisation. Ce qui est cohérent avec une vitesse de requête trop rapide vers le serveur. Je reviens donc avec ma question: existe-t-il un moyen d'allonger le temps de séparation entre des requêtes successives, genre 100 msec par exemple.

Edit: voila j'en ai 10 qui tournent à 300 KB/s pour le moment. Quand un a fini le suivant prend le relais et le fichier qui a presque fini (80%) passe de 2 à une seule connexion, donc ralentit.

Originally Posted by ON5MJ

existe-t-il un moyen d'allonger le temps de séparation entre des requêtes successives, genre 100 msec par exemple.

Non, je ne crois pas qu'une telle fonction existe.

Voilà peut-être une suggestion à faire par ceux qui savent à qui s'adresser.

Je l'ai faite, mais je ne suis pas sur qu'elle soit acceptée par les dévellopeurs

Bonjour,

Je reviens un instant sur le sujet avec quelques expériences tentées sur FilePost avec un compte premium, sur plusieurs jours et plusieurs GB. A noter que la dernière version de JDL et mises a à jours sont installés.

1. Si je dépasse au départ 4 fichiers à charger en parallèle les messages d'erreur apparaissent.

2. Avec 4 fichiers en parallèle la vitesse globale de connexion au serveur est inférieure au 1/4 de mon débit normal. Probablement parce que FilePost limite le débit par fichier en fonction de la charge générale du serveur à cet instant, par contre il ne me limite pas en nombre de fichiers en parallèle.

3. Si la liste est chargée dans JDL, que le téléchargement est lancé en commençant par 4 fichiers et que je monte progressivement le nombre de fichiers en parallèle avec les flèches aucun message d'erreur apparaît et la vitesse globale de téléchargement monte très rapidement au plein débit.

4. Dès qu'un fichier a fini de charger un autre le remplace.

5. A noter que quand une erreur se produit elle met le fichier de côté pendant 10 minutes. Je n'ai pas attendu pour voir si ces fichiers sont recyclés automatiquement après le délai.

6. Je n'avais jamais observé ce phénomène dans les mêmes conditions (20 en parallèle directement) sur FileSonic précédemment, ni sur Rapidshare. De même cela ne se passait pas sur Filepost avant la fermeture de Megaupload.

Ceci prouve à mon sens que le problème se trouve sur le serveur qui ne parvient pas à digérer une rafale de requêtes d'un coup. En montant progressivement la charge les nouvelles requêtes arrivent avec un petit décalage de temps et tout baigne dans l'huile. D'où l'intérêt de pouvoir paramétrer un petit délai soi-même. J'imagine qu'une temporisation ne doit pas être excessivement difficile à programmer mais par contre adapter l'interface utilisateur est certainement plus lourd à réaliser ainsi que la sauvegarde des paramètres sur le PC de l'utilisateur.

Bref tout cela pour dire que j'aimerais vraiment bien que l'équipe de développement se penche sur ma solution. Merci de votre attention.

Edit: je viens de lire les détails de la réponse de Raztoki. Je suis bien d'accord de penser qu'il s'agit d'une surcharge due à la migration d'uploaders après l'épisode de Megaupload et Filesonic. Il ne sait peut-être pas cependant qu'il s'agit d'un compte premium pour lequel il n'y a pas usage de captcha. Et je trouve délicieux de penser que mettre un délai aléatoire pourrait contourner la détection de JDL comme s'il s'agissait d'un chargement à partir d'un navigateur. Mais dans ce cas il serait utile de ne temporiser que pour les serveurs qui détectent JDL, les autres seraient pénalisés inutilement.

Apparemment je n'ai pas accès dans cette discussion ?

Originally Posted by ON5MJ

Apparemment je n'ai pas accès dans cette discussion ?

Non, elle est réservée aux devs et aux "rapporteurs de bugs".

Vous pouvez me donner votre réponse (de préférence en anglais), je la transmettrai aux personnes intéressés

Facts-

W7 64 bits Ultimate - 12 GB RAM - lot of space on SATA HD
jDownloader has been updated properly.
DNS servers: primary Google and secondary OpenDNS
Internet connection: VDSL2
Normal line throughput: 3 MB/s down
hoster: FilePost
account: premium thus no captcha to fulfill
test campaign: a few days and many GB and files.
no other download at the same time even through the browser

Tests-

1. If I setup jDL for 5+ simultaneous files for downloading, error messages appear. Errors are scattered among files without predictible pops. This happens for any connection number from 1 to 5.

2. At 4 simultaneous downlads there are no more errors but the download throughput is reduced to less than a quarter (between 300 and 600 KB/s following the max connection number). Filepost probably limits the bandwidth of each file depending of the load of their servers and available bandwidth at the moment. Nonetheless they don't limit my allowed simultaneous files number.

3. Starting at 4 simultaneous downloading files and increasing step by step this number with the little arrow in the status bar (or by launching manually another file in the list) no error message is triggered even up to 20 files in parallel and the download throughput increases accordingly up to the maximum line throughput. I increased the max connection up to 5, nevertheless if the number remains low (1 or 2) the download speed per file remains a bit lower. I also observed that the used connections number is alwaysautomatically reduced step by step at 80% of the download, up to 1 connection at the end. The download speed is reduced accordingly.

Consequently this means that we have the choice between: downloading without error messages at a lower pace (20 - 25% only) and increasing manually the number of parallel downloading files.

4. As soon as a file is downloaded, it is replaced by the next one in the list without any problem.

5. Error messages ask to retry in another 10 minutes. Nevertheless I never waited to the end because reinitiating manually the download works immediatly.

6. Before the closing of Megaupload 2 weeks ago and the withdrawal of Filesonic from the scene, I never experienced this problem on Filepost, Megaupload, Rapidshare, Filesonic and others. Even on Filesonic during 2 days between the closing of MU and FS withdrawal.

These symptoms seem to prove that the error originates at the server side that is unable to cope with its new increased load and fast file requests. Maybe this could be improved in allowing the final user to setup globally or specifically for a few servers a time delay between two successive requests.

Following your reply to fma16, it's fun to thing a delay could be a possible solution as well to bypass the detection of jDL by a few file servers, provided that the delay would have a random pattern. Nevertheless this solution is not advisable to be general as all servers don't block jDL.

Regards.

Vu la longueur de votre réponse, et le fait qu'elle implique une discussion, j'ai préféré créer un sujet dans le forum : http://board.jdownloader.org/showthread.php?p=189788
J'espère que ne vous m'en voudrez pas

non pas du tout

Je croyais être dans le forum (;-0) N'est-ce que l'anglais qui diffère ? Avantage dans ce cas c'est qu'on touche plus de monde et que des problèmes similaires pourraient remonter à la surface. NB je comprends bien que l'équipe a peut-être des sujets plus croustillants à traiter en priorité.

So, do you suggest to abandon this French discussion and switch to the English one, just in case ?

Dans le ticket Jiaz a dit que dans le cas d'un serveur surchargé, jD (ou le client) ne peut rien faire.

Le problème n'est pas aussi étroit. Si le serveur est surchargé et ne peut répondre à des requêtes rapprochées en rafale, par contre il répond à des requêtes manuelles donc retardées et aléatoires. Au moins il n'y a pas de message d'erreur. On lance et on revient quand c'est fini.

En fait comme on n'a jamais testé on ne sait pas si jDL peut faire quelque chose. Je pense que oui dans certains cas. D'ailleurs c'est la technique utilisée en réseau LAN Ethernet quand il y a des collisions de messages issus de clients différents. On remet les envois à zéro et on relance de nouveaux envois après un temps minimum mais aléatoire (et une écoute du trafic sur la ligne).

FilePost complètement sur les rotules aujourd'hui: max 20 à 50 KB/s par fichier. Leurs serveurs naviguent vraiment à la rame !

Je suggère, comme vous l'avez dit, de passer sur le sujet anglais. Les personnes sont beaucoup plus compétentes que moi, et pourront mieux répondre à votre question, qui est assez complexe puisque touche au noyau de jD.

Personnellement, je pense moi même que votre idée de pouvoir modifier manuellement ce paramètre est bonne, et pourrait résoudre de tels problèmes.

Ils ne sont pas idiots, donc si à première vue je pose un problème dont ils se passeraient bien, à seconde vue cela va quand même cogiter entre leur chaise et leur clavier. Je crois surtout que c'est l'interfaçage utilisateur qui est lourd à résoudre.

Vous avez tout bon!