Quote:
Originally Posted by Showboat
Muss also irgendwo an Uploaded oder JDownloader liegen. Ich finde es komisch dass wir User nicht alle am gleichen Limit hängen.
|
Meine Vermutung ist das es mit der Verschlüsselung und JDownloader im Zusammenhang steht.
Jedenfalls wenn die CPU stark ausgelastet dabei ist.
Sowohl mehrere Hoster haben dazu aufgerüstet auf HTTPS, die Welt verlangt immer stärkere automatische Verschlüsselung und beim dritten Grund bin ich mir unsicher ob in JD die Lib dazu aktualisiert wurde.
Auch weil die Optionen im JDownloader nicht vollständig sicherstellen das es ohne Verschlüsselung erfolgt meines Wissens aber im Prinzip so sein sollte. Nur man müsste jede Verbindung/Link auch Weiterleitungen dazu nachprüfen im Code oder wenigstens mal Wireshark/Fiddler per Desktop+JD nutzen um zu überprüfen ob es tatsächlich ohne Verschlüsselung erfolgt. Vielleicht kennt einer der JD Entwickler in Java bessere Möglichkeiten dazu.
Hab leider keinen Premiumaccount von Uploaded um dies kurz zu überprüfen.
Quote:
Originally Posted by Showboat
Es scheint also doch irgendwo am Anschluss des Users zu liegen, wieviel "kastrierte" Bandbreite ankommt.
|
Man müsste mal zusätzlich schauen ob es verschiedene Boxen mit unterschiedlicher Hardware (insbesondere CPU) sind. Bin für andere Vorschläge und Lösungsansätze offen aber mit Pyload+DirektHTTP scheint es ja zu funktionieren.
Kastrierte Bandbreite kann ich mir in dem Fall nicht vorstellen bis 100 mbit/s sollte es problemlos gehen und dann wäre es auch bei allen Downloads. In der Theorie könnte man einen stabilen SOCKS/HTTPS Proxy oder VPN nutzen um eine kastrierte Bandbreite auszuschließen.