[blacksun]

Hallo zusammen,

in Spitzenzeiten wie z.B. aktuell am Samstag-Nachmittag, wo sehr viele Leute laden, ist dann kein Download mehr als Freeloader möglich, auch nicht mit Free-Account.
Im JD steht dann "Download im Moment nicht möglich" oder "No Free Downloads-Slots".
Der JD springt dann immer weiter zum nächsten File, solange bis er eines findet welches er wieder laden kann.

An sich eine gute Idee, die auch so funktioniert. Bis vor kurzem war das auch vollkommen in Ordnung, da ul.to/.net keine Captchas hatte.

Da ul.net nun aber wieder reCaptcha verwendet und es im Moment nur eine brauchbare Methode zur automatischen Lösung gibt, nämlich CBH, ist das insofern etwas ungeschickt, da für jeden Versuch ein Credit verbraten wird.
Sprich für jeden Versuch muss ein Captcha eingegeben werden.

Hier wäre mein Vorschlag, dass man dem Plugin Plugin-Einstellungen gibt, so dass die Anwender jeweils wählen können, was bei diesem Zustand passieren soll. Mein Vorschlag wären "warte x Minuten", "reconnect" und "springe immer weiter zum nächsten File (wie bisher)".

Das Plugin an sich funktioniert tadellos. Da muss nichts angepasst werden. Nur die Auswahlmöglichkeit für obige Situation wäre in diesem Fall hilfreich.

Was meint ihr?

jdlog://1345908375427

[oEFLKQzikCqw]

Also in JD2 wird nur solange zur nächsten Datei gesprungen, bis man alle Freeaccs durch hat. Dann macht der JD noch einen Versuch ohne Account und dann wird gewartet, wenn ich mich nicht irre warten es 5 Min. Die Benutzung von UL.to-Free-Accs funktioniert in JD2 auf jeden Fall besser als in der Stable.

[blacksun]

das mag schon sein, aber die vielen Versuche kosten trotzdem jede Menge Credits.
Wie gesagt soll ja an sich an der Funktionalität nichts verändert werden, der Anwender soll nur die Möglichkeit zu haben per Häkchen zu setzen zu entscheiden wie in solchen Fällen vorgegangen wird.
Wenn ich z.B. am PC sitze und die Captchas selbst eingebe, dann spielt das in der Tat keine Rolle und ist auch gut so.
Aber bei fremdem Lösen kostet es bei 20 Free-Accounts einfach zu viele Credits.

Jetzt fragst Du warum 20 Accounts?
Die braucht man, da man pro ca. 1 Std ein File pro Account laden kann. Sprich mit den 20 Accounts sorgt man dafür dass man keine Wartezeit hat. Wenn der JD beim 20. Account angekommen ist haben die ersten Accounts schon wieder die Wartezeit fertig durchlaufen.

edit://
und wenn ich das richtig beobachtet habe kostet jedes File ohnehin mind. 2 Credits, da der JD bei Free-Accounts nach einem DL mit einem Account das nächste File mit dem gleichen Account probiert und erst dann zum nächsten Account geht. Auch dieser Versuch kostet natürlich wieder einen Credit.

[pspzockerscene]

Bitte schick mir mal einige Accounts und Beispiellinks per PM, eventuell schaue ich mir das mal an.
Man man das wird ein gefriemel...

GreeZ pspzockerscene

[blacksun]

@PSP
Du hast eine PM.

Übrigens hab ich nochmal eine Credit-Verschwendung entdeckt. Hat man mehrere Mirrors einer Datei in der Downloadliste, werden die Mirrors nicht dann erst deaktiviert, wenn das File von einem Hoster fertig geladenw wurde, sondern das Mirror-File wird trotzdem angestartet.
Bsp:
datei1.rar wurde von share-online fertig geladen. datei1.rar ist aber auch noch im gleichen paket von ul.net in der liste. Dann wird dieser Eintrag erst dann auf deaktiviert gesetzt, wenn das File gestartet wurde.
Und auch für diesen sinnlosen Startversuch muss wieder ein Captcha eingegeben werden, sprich es werden sinnlos Credits bei CBH verbraucht.

Im Schnitt braucht man so mind. 5 Captchas und damit Credits pro Datei, von denen 4 gar nicht nötig wären. Hinzu kommen dann auch noch die Captchas die falsch über CBH hereinkommen.

[blacksun]

Hallo PSP,

so, ich hab das ganze mal festgehalten, wie das mit dem Limit beim Free-Account aussieht:



hier die html-dateien der seite:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

[pspzockerscene]

@blacksun
Danke.
Das mit dem Mirror Problem ist ein übergeordnetes JD2 Problem und hat nix mit dem Plugin zu tun.
Ich werd mich um das Limit Zeugs kümmern, sobald ich Zeit dafür hab!

GreeZ pspzockerscene

[blacksun]

Originally Posted by pspzockerscene

Das mit dem Mirror Problem ist ein übergeordnetes JD2 Problem und hat nix mit dem Plugin zu tun.
Ich werd mich um das Limit Zeugs kümmern, sobald ich Zeit dafür hab!

Das mit dem Mirror dachte ich mir schon.

Beim Plugin selbst sind es dann drei Probleme die zu einer Creditverschwendung führen.

- ul.net ist ausgelastet weil gerade in der Spitzenzeit viele laden. Es sind keine Free Downloadslots verfügbar. Trotzdem probiert der JD weiter.
Lösung: Das Plugin bekommt eine Option für den Anwender was passieren soll. Mögliche Optionen: Warte xx Minuten bevor nächstes ul.net-File probiert wird oder probiere gleich weitere ul.net-Files
Idealer weise sollte der Anwender auch gleich die Zeit noch einstellen können die dann gewartet wird.

-ein Account hat das DL-Limit erreich. Dennoch probiert der JD weiter mit diesem Account zu laden.
Lösung: Der Account (und nur der betroffene Account!) bekommt eine Wartezeit von einer Stunde. Während dieser einen Stunde benutzt JD diesen Account nicht mehr sondern die verbleibenden ohne Wartezeit.
Ist kein weiterer Account ohne Wartezeit mehr vorhanden dann wie bisher auch noch einen Versuch ohne Account

- ein File wurde mit einem Account geladen und es sind noch weitere ul.net-Files in der Warteschlange. Dann wird vom JD versucht das nächste File zunächst mit dem Account zu laden, mit dem gerade ein File geladen wurde.
Lösung: JD sollte gleich zum nächsten Account weiterspringen.

[oEFLKQzikCqw]

Die Vorschläge finde ich gut. Leider lässt sich damit ein Problem nicht lösen: Die Fehlermeldungen, wie DL-Limit erreicht oder keine Freeslots verfügbar, bekommt man in der Regel erst nach dem Lösen des Captchas.

Noch ein Vorschlag: Wenn man gerade mit einem Free-Acc oder ohne Acc eine Datei geladen hat, bei den betroffenen Accs sofort die Wartezeit starten, wobei die bereits mit dem DL-Start und nicht erst mit dem Ende beginnt. Zur Sicherheit kann man da noch einen Puffer von 1-2 Minuten draufschlagen wenn nötig (siehe Die eine Stunde bei uploaded.to).

[blacksun]

Originally Posted by oEFLKQzikCqw

Die Vorschläge finde ich gut. Leider lässt sich damit ein Problem nicht lösen: Die Fehlermeldungen, wie DL-Limit erreicht oder keie Freeslots verfügbar, bekommt man in der Regel erst nach dem Lösen des Captchas.

richtig, aber das Problem ist ja, dass der JD es mehrmals probiert und dass so Credits verschwendet werden.
In Spitzenzeiten haben ja viele Dateien "keine Freeslots" mehr. Habe ich 100 Links in der DL-Liste, dann probiert der JD unendlich durch, bis er wieder einen Link findet, der diesen Status nicht mehr hat.
Genau deshalb hatte ich ja geschrieben man soll das als Option zum Auswählen für den Anwender umsetzen. Ich als CBH-User würde dann die Option wählen "sobald JD auf ein File mit Status "kein Freeslot" trifft warte XX Minuten". Dann würde der JD solange keine weiteren Files probieren.
Andere Anwender, die selbst Captchas eingeben oder eine andere Methode ohne Creditproblem nutzen wählen die Option "nächsten Link versuchen", bei der sich der JD wie bisher verhält und unendlich oft Files probiert, bis er wieder eines findet das einen Freeslot hat.
Somit kann jeder selbst entscheiden was ihm lieber ist, ob möglichst wenig Credits verschwenden oder möglichst schnell mit dem DL fertig sein.
Und ich hatte ja geschrieben dass der Anwender im Fall von "Warte XX Minuten" auch die Minutenzahl einstellen kann, die gewartet wird, so dass er auch hier entscheiden kann wie viele Captchas er opfert. Der eine nimmt 10 Minuten, ein anderer 30, ein anderer 60 Minuten.

Auch wenn ein Account das DL-Limit erreicht hat habe ich festgestellt, dass der JD diesen Status wohl nicht auswertet. Ich habe z.B. 15 Accounts in meiner Account-Liste und auch wenn die alle ein Limit haben muss ich mehr wie 16 Captchas lösen (1x15 pro Account + 1 Versuch ohne Account). Das zeigt mir dass JD einen Account mehr wie einmal probiert. Daher sollte ein Account sofort nachdem ein Limit festgestellt wurde auf eine Wartezeit von mind. 1 Std gesetzt werden, bevor der Account das nächste mal benutzt werden kann.
So habe ich zwar dann immer noch 15 Captcha-Credits ohne dass ein File startet, aber eben nicht mehr.

Der letzte Punkt sollte sogar ganz ohne sinnlose Captcha-Eingabe machbar sein. Wurde ein File mit einem Account fertig geladen wird der Account sofort für 1 Stunde gesperrt und das nächste File wird gleich mit einem anderen Account probiert.
Bisher probiert der JD auch das zweite File zunächst mit dem gleichen Account (mit Captcha-Eingabe) und nutzt erst dann den nächsten Account. Somit brauche ich also im allergünstigsten Fall mind. 2 Captchas pro File.

[pspzockerscene]

Bzlg. der Slots habe ich (noch) nix verändert (bitte teilt mir mit, was ihr an der Stelle konkret haben möchtet!), aber bzlg. der Free Accounts:
Ab dem nächsten Update (bzw. in der BETA sofort) kann man in den Plugin Einstellungen bei uploaded.to bei folgender Einstellung ein Häckchen setzen:
"Activate experimental free account errorhandling: Swith between free accounts instead of reconnecting if a limit is reached."
Das Verhalten mit aktivierter Einstellung ist dann so:
Download über Account->JD speichert, dass mit dem Account etwas geladen wird (der Haken: Die verwendete IP wird dabei nicht beachtet)->JD versuchtm mit demselben Account wieder ein File zu laden, bemerkt aber, dass der letzte Download noch keine 60 Min her sind und deaktiviert den Account (der Acc wird für 60 Min deaktiviert, leider kann ich nicht bestimmen, für welche Zeit Accounts deaktiviert werden (Zeit ist fest, passt in diesem Fall sogar super)->Download der nächsten Datei über den nächsten Account.
Sind irgendwann alle Accounts deaktiviert, wird per Free weitergeladen (es sei denn die Wartezeit ist schon wieder vorbei, dann gehts wieder mit dem Anfangsaccount weiter).

Bitte testen und Feedback hier posten.
Die Enstellung dafür habe ich extra gemacht, damit Fehler meinerseits keinen Einfluss auf das für andere User gewohnte Verhalten haben.
Außerdem solltet ihr bedenken, dass uploaded diese kleine "Lücke" sicherlich schnellstmöglich beheben wird, wenn sie das merken.
Ich schätze mal, deren System ist nicht so gemacht, dass sie Wartezeiten global verwalten und das lässt sich nicht so einfach ändern, evtl. sitzen sie ja schon dran, das zu ändern^^

GreeZ pspzockerscene
EDIT

Habe nun ne Methode, um die genutzte IP zu bekommen.
Wenn man nen Account benutzt, da ein Limit drauf ist und reconnectet, ist es dann weg?

[blacksun]

Originally Posted by pspzockerscene

Bzlg. der Slots habe ich (noch) nix verändert (bitte teilt mir mit, was ihr an der Stelle konkret haben möchtet!), aber bzlg. der Free Accounts:
Ab dem nächsten Update (bzw. in der BETA sofort)...

super, da freu ich mich schon drauf, wie das dann so läuft.

wegen der Slot-Meldung.
Am schönsten wäre wenn man per Plugin-Einstellung bestimmen könnte wie lange der JD bei "keine Slots frei" wartet bevor er das nächste File probiert.
Mein Vorschlag:
Eine Option "Wartezeit", die nur für die keine Slots frei gilt. Damit sie für die User die keine Veränderung wollen unverändert bleibt kann sie auf 0 stellen. D.h. der JD wartet 0 Minuten und probiert gleich das nächste File.
Ich persönlich hingegen würde die Wartezeit auf 15 Minuten setzen (auch als default, damit der Hoster nicht unnötig belastet wird, bzw. auch damit CBH nicht unnötig belastet wird)

D.h. sobald irgend ein File von diesem Hoster auf die Slot-Meldung trifft, wird mit dem nächsten ul.net File 15 Minuten gewartet.

Ich denke das würde allen Wünschen gerecht werden.

[oEFLKQzikCqw]

Originally Posted by blacksun

richtig, aber das Problem ist ja, dass der JD es mehrmals probiert und dass so Credits verschwendet werden.
In Spitzenzeiten haben ja viele Dateien "keine Freeslots" mehr. Habe ich 100 Links in der DL-Liste, dann probiert der JD unendlich durch, bis er wieder einen Link findet, der diesen Status nicht mehr hat.

Das habe ich so im JD2 bisher noch nicht beobachten können., in der Stable aber schon. Letztere benutze ich allerdings nicht mehr zum DL mit UL.to-Free-Accs.

Originally Posted by pspzockerscene

Ab dem nächsten Update (bzw. in der BETA sofort) kann man in den Plugin Einstellungen bei uploaded.to bei folgender Einstellung ein Häckchen setzen:
"Activate experimental free account errorhandling: Swith between free accounts instead of reconnecting if a limit is reached."
Das Verhalten mit aktivierter Einstellung ist dann so:
Download über Account->JD speichert, dass mit dem Account etwas geladen wird (der Haken: Die verwendete IP wird dabei nicht beachtet)->JD versuchtm mit demselben Account wieder ein File zu laden, bemerkt aber, dass der letzte Download noch keine 60 Min her sind und deaktiviert den Account (der Acc wird für 60 Min deaktiviert, leider kann ich nicht bestimmen, für welche Zeit Accounts deaktiviert werden (Zeit ist fest, passt in diesem Fall sogar super)->Download der nächsten Datei über den nächsten Account.
Sind irgendwann alle Accounts deaktiviert, wird per Free weitergeladen (es sei denn die Wartezeit ist schon wieder vorbei, dann gehts wieder mit dem Anfangsaccount weiter).

Hört sich gut an. Mal die Praxis abwarten.

Originally Posted by pspzockerscene

Habe nun ne Methode, um die genutzte IP zu bekommen. Wenn man nen Account benutzt, da ein Limit drauf ist und reconnectet, ist es dann weg?

Warum sollte es? Schließlich kann man das Limit bei Accs ja am Acc festmachen und braucht dafür nicht mehr die IP.

[pspzockerscene]

Originally Posted by oEFLKQzikCqw

Warum sollte es? Schließlich kann man das Limit bei Accs ja am Acc festmachen und braucht dafür nicht mehr die IP.

Weil das Limit bei vielen Hostern (besonders bei denen mit Fertigscripten) nur auf der IP und nicht aufm Account liegt.

Uploaded.to hat ja auch vergessen (denke ich zumindest), es eben so zu machen, dass das Limit auf der IP und aufm Account liegt.

Ich habe eine weitere Einstellung hinzugefügt, die auch unnötige Captchas bei nichtbenutzung von Accounts verhindern soll.

GreeZ pspzockerscene
EDIT

Die Änderungen sind ab jetzt live (JD2BETA), viel Spaß damit, freudiges Testen und reporten!

[blacksun]

Originally Posted by oEFLKQzikCqw

Das habe ich so im JD2 bisher noch nicht beobachten können., in der Stable aber schon. Letztere benutze ich allerdings nicht mehr zum DL mit UL.to-Free-Accs.

Das mit mehreren Accounts benutzen funktioniert ja auch nur im JD2, da nur hier automatisch zwischen den Accounts gewechselt wird.

Auch wenn der ul.net bei einem File meldet, dass keine Freeslots verfügbar wären, macht es grundsätzlich keinen Sinn, dass der JD weitere Files probiert, auch nicht mit weiteren Accounts, da viele andere Files (nicht alle) auch keine DL-Slots mehr haben.
Wenn man CBH zur automatisierten Lösung der reCaptchas nutzt verbraucht man dann nur unnötig Credits.
Deshalb mein Vorschlag, dass der JD dann wartet.

Wenn man aber die Captchas selbst eingibt, dann kann bräuchte man keine Wartezeit und man ohne Wartezeit gleich weiter probieren, damit mit die wenigen Files "erwischt", die noch einen Slot haben.

Um beiden Anforderungen gerecht zu werden war eben mein Vorschlag, dass es eine Option gibt, mit der man die Wartezeit bis zum nächsten File bestimmen kann. 0 wäre dann die Einstellung für die Selbsteingeber, und die CBH-Nutzer könnten dann einen höheren Wert nehmen, z.B. 15 Minuten.

[pspzockerscene]

Kay da werde ich mal schauen, ob/wie sich das einrichten lässt.
Momentan sollte JD bei keinen Slots 10 Minuten warten OHNE weitere Links durchzuprobieren!

GreeZ pspzockerscene

[blacksun]

Originally Posted by pspzockerscene

Kay da werde ich mal schauen, ob/wie sich das einrichten lässt.
Momentan sollte JD bei keinen Slots 10 Minuten warten OHNE weitere Links durchzuprobieren!

GreeZ pspzockerscene

irgendwo hat sich evtl ein Fehler eingeschlichen.
Die einzelnen Files laufen nun auf "Plugin defekt" nachdem der Countdown von 30 Sekunden abgelaufen ist.

Hier das Log:
jdlog://1346264106581





edit:
ich habe so eine Vermutung (ist aber nur eine Vermutung).
evlt. hat sich die "keine Slot"-Meldung geändert bzw. wird nicht richtig interpretiert
evtl. war's auch nur ein temporäres problem, weil jetzt läuft es plötzlich
[/b]

edit2:
Du hast geschrieben ,dass ein Account, wenn er benutzt wurde, eine Wartezeit von 60 Minuten erhält (was ja auch passt)
Im JD sieht das dann zuerst wie folgt aus



nach den knapp 5 minuten sehen die benutzten accounts wie folgt aus



haben die accounts dann eine wartezeit von knapp 5 Minuten oder doch von einer Stunde??

[pspzockerscene]

Ich hoffe die Fehler passieren nur, wenn die Einstellung aktiviert ist, denn ich wollte nicht, dass sich noch mehr User wegen irgendwelchen unnötigen Problemen beschweren^^

Also bei mir waren die Accounts (in der Entwicklerversion) für 60 Min deaktiviert und das konnte ich wie gesagt auch nicht beeinflussen.
Wie lange sie deaktiviert sind sollte eig. relativ egal sein, da JD erkennen sollte, dass das Limit noch aktiv ist noch bevor du ein Captcha eingeben musst (geht das wenigstens?).

GreeZ pspzockerscene

[blacksun]

also, ich kann Entwarnung geben, es scheint sich wohl tatsächlich um ein temporäres Problem gehandelt zu haben. Ich habe den JD heute Nacht mal saugen lassen und so wie es aussieht hat das alles funktioniert.
Natürlich war heute Nacht keine Spitzenzeit, sprich es gab auch keine "keine Slots mehr frei Meldungen" und ich verwende ja auch viele Accounts.

klar, ich als Tester hatte die beiden Optionen auch an.
Dass die große Masse der Anwender nichts bemerkt hat sieht man ja daran dass es keine Posts im Forum gab. So verbreitet wie der Hoster ist hätte es längst schon eine Flut an Postings gegeben.


Du hattest oben die Option "Activate experimental free account errorhandling: Swith between free accounts instead of reconnecting if a limit is reached." schön erklärt.

Was genau macht die Option "Activate experimental reconnect handling for freeusers: Prevents having to enter captchas in between downloads"?

edit wegen Frage nach der Erkennung des Account-Limit:
Also rein dem ersten Screen nach würde ich sagen dass die Accounts nur 5 Minuten deaktiviert werden. Aber ich kann tatsächlich bestätigen dass das Plugin erkennen kann ob ein Account noch ein Limit hat ohne dass ein Captcha eingegeben werden muss.
Wie auch immer Du das hinbekommen hast, Kompliment.
Weil eigentlich geht das erst nach der Captcha-Eingabe.

Jetzt bleibt nur noch das Problem mit dem Credit-Wasting wenn keine Slots mehr verfügbar sind, dass der JD dann wartet und nicht einfach weiter probiert. Hier habe ich gestern Abend meine ich noch keine Verbesserung gesehen. Das der JD einfach weiter probiert obwohl ein File auf "kein Slot" läuft verbraucht im Moment noch die meisten sinnlosen Captchas. Ist hier schon was im Plugin eingebaut?
Testen kann ich das natürlich erst heute Nachmittag bzw. heute Abend, wenn auch wieder viel gesaugt wird.

[blacksun]

also, nochmal als Nachtrag zum Posting von heute morgen:
gerade war es soweit, ein File hatte den Status "keine DL-Slots" und der JD hat nicht gewartet.

jdlog://1346325571614


edit:
so nun, sind wir in der spitzenzeit angekommen, alle files bringen nacheinander "no free downloadslots available"
jdlog://1346332221708
und CBH muss jede menge sinnlose Captchas lösen

nach einer Weile dieser sinnlosen Captchas tritt dann auch wieder das Problem mit "Plugin defekt" auf, das ich ja oben ausführlich mit Screens dargestellt habe. Also insofern kein temporäres Problem, sondern es hängt tatsächlich mit den "keine Slots"-Thema zusammen.
hier das Log mit dem "Plugin-defekt":
jdlog://1346332687622