#1
|
|||
|
|||
Packagizer, prio nach Hoster und FF-Addon
Um tägliche Limits zu schonen, bei kompatiblen Links von verschiedenen Hostern, habe ich im Packagizer eine Regel erstellt. So bekommen die Links eines Packets von Uploaded eine normale Prio vor dem DL und alle anderen eine Prio von +1.
Wenn ich nun in der Oberfläsche von my.JD mehrere Links zusammen hinzufüge funktioniert es. Füge ich einen einzellnen Link via rechtsklick mit FF-Addon als "einen Link Hinzufügen" hinzu, so funktioniert es ebenfalls. Verwende ich jedoch "Auswahl hinzufügen" oder "Seite hinzufügen" via Addon ein so funktioniert es bei mir nicht. Übersehe ich da was oder ist es ein Fehler in JD? Wenn es ein Fehler ist, was braucht Ihr von mir alles um es reproduzieren und Testen zu können? Ich stehe Gewehr bei Fuß. Ich habe mit Dowload-Url und quell-url probiert. Der geschilderte Stand ist mit Quelle(n). |
#2
|
||||
|
||||
Zeig mal die Regel (Screenshot). Denke es ist ein simpler Fehler in der Regel, denn alle Links durchwandern die Regeln
__________________
JD-Dev & Server-Admin |
#3
|
|||
|
|||
Habe sie ganz ganz Simpel. Nur Quell-Url(s) not Uploaded und Prio +1, sonst nix. Und da fehlt mir gedanklich sicher was. So einfach kann es doch nicht sein?
Was mir auch nicht gelingt ist uploaded.net,ul.to,ul.net,uploaded.to. Habe es so verstanden dass das Komma als "oder" funktioniert, aber da liege ich wohl falsch(?) Screenshot anbei. |
#4
|
||||
|
||||
DownloadURL enthält oder enthält nicht
.*(uploaded\.to|uploaded\.net|ul\.to).+ Rechts die Checkbox bei Regex aktivieren QuellURL -> Alle URLs die bis zum Download führen DownloadURL -> Der Download selbst
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
Das mit den unterschiedlichen Schreibweisen für UL funktioniert nun, danke. Aber für Rechtsklick und "Download selection" und "Download Page" im FF greift/funktioniert es bei mir immer noch nicht.
Wenn es am FF-Addon liegen würde das Packagizer-Regeln nicht greifen, dann wäre das doch sicher schon längst aufgefallen. Das Problem sitz hier doch wieder 60 cm vor dem Schirm(?) |
#6
|
|||
|
|||
Quote:
.*(uploaded\.(to|net)|ul\.to).+ |
#7
|
||||
|
||||
Ursache gefunden! Mit nächstem Core Update fixed
__________________
JD-Dev & Server-Admin |
#8
|
|||
|
|||
Thnx Jiaz.
Ich hatte da noch was anderes probiert und nicht erreicht was ich wollte, was zum Thema passt. Wenn ich nach dem Entpacken verschiebe, dann werden Unterordner nicht übernommen, sondern alle Dateien landen direkt im neuen Hauptordner. Dies wäre zB bei DVD- oder BD-Verzeichnissstruckturen aber relevant. Mit meiner Suche bin ich nicht fündig geworden... Wie kann ich das im Packagizer richtig machen oder müsste dies per Ereigneiss/Script gemacht werden? |
#9
|
||||
|
||||
Settings -> Archiventpacker und dort kannst du
1.) dem EntpackOrdner ändern 2.) zusätzlich UnterOrdner erstellen lassen Der Packagizer arbeitet auf Datei-Ebene und folglich werden nur Dateien verschoben. Nutze die Archiventpacker Einstellungen für was du vor hast EntpackOrdner auf f:\test UnterOrdner einschalten, dann 0 / 0 / 1 und entweder %PACKAGENAME% oder %ARCHIVENAME% (RechtsklickMenu) nehmen
__________________
JD-Dev & Server-Admin |
#10
|
|||
|
|||
Einen eigenen Unterordner für das Entpacken zu haben, dass bekomme ich Blödmansgehilfe hin.
Mir ging es dabei wirklich nach dem erfolgreichen Entpacken zu verschieben. Hintergrund ist, dass JD ja auf dem Server läuft und ich ein paar Mal von Hand verschoben hatte obwohl JD noch am entpacken war. Dann muss ich einfach wirklich dran denken erst den Monitor auf den Server zu schalten und zu schauen ob er entpackt bevor ich was von Hand verschiebe. :D Das Update habe ich installiert und die Prios gehen nun auch für das AddOn. |
#11
|
||||
|
||||
???
Einfach noch den EntpackOrdner ändern und du hast genau das was du willst!? Entpacken auf F:\Test\Paketnamen. Warum erst entpacken und dann verschieben? Dann lass doch gleich an den richtigen Ort entpacken?
__________________
JD-Dev & Server-Admin |
#12
|
|||
|
|||
Wie gesagt... Ich will die Fertigen dann auf ein lokales Laufwerk verschieben und bin manchmal zu doof erst zu schauen ob JD noch am entpacken ist.
|
#13
|
||||
|
||||
Ach F:\Test ist gar nicht das "Ziel" ?
__________________
JD-Dev & Server-Admin |
#14
|
|||
|
|||
Neee, das Ziel nach dem Ziel.
|
#15
|
||||
|
||||
also du willst nach f:\test entpacken lassen und danah verschiebst du nochmal?
__________________
JD-Dev & Server-Admin |
#16
|
|||
|
|||
genau das Prinzip..
Entpacken geht nach .../extract/Packetname/ Die fertig Entpackten sollen dann weiter nach ... samt Unterordner Also in meinem Test: .../test/Packetname/mögliche unterordner/*.* |
#17
|
||||
|
||||
Aber warum dann nicht gleich nach /test/Paketnamen entpacken? Verstehe nicht warum man nen weiteren ZwischenOrdner haben wollen würde
__________________
JD-Dev & Server-Admin |
#18
|
|||
|
|||
Ich verschiebe halt auf unterschiedliche USB-Laufwerke und ein anderes Ziel auf den Server, das problem ist das ich nicht von and verschieben will, wenn er noch am Entpacken ist. Aber das ist okay, mach Dir da keine weiteren Gedanken.
Zum Eigentlichen Thema des Thread... ARGH! Das Priorisieren funktioniert nun sehr gut, inzwischen bekommt Uploaded -1 und alle Anderen sogar +3. Downloaden tut JD dann aber doch zuerst Uploaded und die Anderen "mirror lädt...". Somit war das ganze für meine Idee ein Satz mit X. :( |
#19
|
|||
|
|||
Hier mal zwei Sceenshots, liegt scheinbar daran das sie in einem Packet sind das die Reihenfolge nicht runtergeladen wird(?)
Last edited by RWeber; 27.09.2015 at 14:00. |
#20
|
||||
|
||||
Hast du denn von allen einen Premium? Denn JDownloader versucht Captchas und co zu vermeiden. Sprich wenn du SO höhere Priorität als UL gibst, aber nur nen UL Premium hast, dann lädt er dennoch via UL, da SO Free ja ein Captcha besitzt
__________________
JD-Dev & Server-Admin |
#21
|
|||
|
|||
Wenn also eine Datei von mehreren Hostern geladen werden kann, wird immer ein Hoster genommen, bei dem kein Captcha erforderlich ist, auch wenn deren Priorität eigentlich niedriger ist? Hoffentlich werden dabei dann aber andere Dateien vom gleichen Hoster mit höherer Priorität berücksichtigt.
Dieses Verhalten kann durchaus sinnvoll sein, wenn Captchas unerwünscht sind. Andererseits will man möglicherweise gewisse Dateien bevorzugt mit anderen Hostern laden, um Traffik beim Hoster mit (Premium-)Account zu sparen für wichtigere Dateien. Wobei das eigentlich trotzdem noch klappen sollte, wenn die wichtigeren Dateien höhere Priorität aufweisen. Wenn man sich aber Traffik für Notfälle und Dateien aufsparen will, die noch nicht in der Downloadliste sind, funktioniert das allerdings nicht. |
#22
|
|||
|
|||
UL ist direkt und Premium und die Anderen sind MOCHs. Sie hatten alle keine Captchas.
Und in den Verwendungsregeln sind sogar die Beiden MOCHs vor Uploaded selbst, für Uploaded. Habe das wie gesagt nur innerhalb eines Packets bemerkt, und zwischen verschiedenen Packeten hat es soweit immer funktioniert mit den Prios. Last edited by RWeber; 28.09.2015 at 07:54. |
#23
|
||||
|
||||
@RWeber:
Original Accounts werden by default immer den Multihostern bevorzugt. Um dies zu ändern, bitte eine HosterRegel in Settings-Accounts für den entsprechenden Hoster anlegen. Grund: Wenn jemand schon einen original Premium Account hat, warum sollte er ihn dann nicht auch für den entsprechenden Hoster verwenden sollen/wollen. Daher ist dies der Default. Kann über eine HosterRegel jedoch gerne abgeändert werden. SO geht (soweit ich weiß) über keinen Multihoster und Mega geht direkt (wegen der Verschlüsselung) ergo nimmt JDownloader den UL Acccount. Da er (in der Auswahl) der einzige mit Premium ist.
__________________
JD-Dev & Server-Admin |
#24
|
||||
|
||||
@oEFLKQzikCqw
Selektion ist in der Reihenfolge Original Account ohne Captcha -> Multihoster Account ohne Captcha -> Free Account ohne Captcha -> Original mit Captcha -> Multi mit Captcha -> Free mit Captcha Andere Dateien vom gleichen Hoster? Du meinst 2 UL Links, einer mit höherer Priorität? Ja das da wird die Priorität beachtet. Wir haben uns dazu entschieden, denn so macht es am meisten Sinn. Den Download so automatisiert wie möglich durchzuführen
__________________
JD-Dev & Server-Admin |
#25
|
|||
|
|||
Quote:
Quote:
Quote:
Ich hätte aber auch erwartet, das der JD den o. die Mirror mit der höheren Priorität bevorzugt. Ja ich weiß, dass eine höhere Priorität nicht unbedingt bedeutet, dass die Datei o. der Link tatsächlich eher zum Zuge kommt. Es gibt da zu viele Umstände (Limits beim Hoster und JD usw.) die da mit hinein spielen. Unter Umständen würde dann eben doch der Mirror mit der niedrigsten Priorität genommen. Wenn das nicht anders geht ist das ja in Ordnung. Die Accountverwendungsregeln helfen im konkreten Fall überhaupt nicht, denn sie eignen sich nicht dafür gewisse Mirror zu priorisieren. Accounts komplett abschalten ist nicht immer eine akzeptable Lösung. Die Links des Hosters mit der niedrigsten Priorität dort zu deaktivieren wo gewünscht, wäre zwar ein Workaround, der im Zweifelsfalle allerdings wieder einen manuellen Eingriff erforderlich machen würde. |
#26
|
||||
|
||||
Grob beschrieben wie der nächste Download gefunden wird
1.) Liste von allen DownloadLinks die Aktiviert und Unfertig sind (AnBhChDnEnhFh) 2.) Liste aus 1 der Priorität nach sortieren (BhChFhAnDnEn) 3.) Durchwandere Liste aus 2 4.) Prüfe Kanditat (zb Bh) und suche alle Mirrors -> Bh1 An En 5.) Prüfe jeden Kandidaten aus 4 auf Wartezeiten, Fehler,AccountVerfügbarkeiten, AccountMöglichkeiten (Origina,Multihoster,Free), Max gleichzeitige Downloads, Hoster Regeln, Domain Regeln, usw -> Bh1 En 6.) Sortiere Liste aus 5 nach "Original Account ohne Captcha -> Multihoster Account ohne Captcha -> Free Account ohne Captcha -> Original mit Captcha -> Multi mit Captcha -> Free mit Captcha" 7.) Versuche Resultat aus 6 8.) Weitere Downloads möglich/erlaubt, gehe zu 2.) Um den Wunsch der Priorität innerhalb von 6.) nachzukommen müsste hierfür jetzt 6.) komplett ignoriert werden und die höchste Priorität verwendet werden. Dies könnte man natürlich über eine Advanced Option global einstellen, ich kann gerne sowas einbauen. Aber auch dann kann die Priorität nicht garantiert werden zb UL steht auf Hoch, hat keinen Premium und ein Download läuft bereits ein Mirror SO steht auf LO, hat Premium Soll jetzt JD absichtlich warten auf UL und somit ein möglicher Download ignoriert werden oder darf JD jetzt auf SO ausweichen obwohl UL eine höhere Priorität hat. Im ersten Fall wundert sich der Nutzer also warum nichts lädt, obwohl doch ein Mirror laden könnte. Im zweiten Fall ärgert sich der Nutzer warum SO genutzt wird, obwohl er UL bevorzugen will. Das Thema ist sehr komplex und unser Ziel war es die Downloads soweit wie möglich zu automatisieren, sprich keine Wartezeiten/Captchas/high Speed. Ich höre mir gerne Vorschläge an
__________________
JD-Dev & Server-Admin |
#27
|
||||
|
||||
Quote:
Quote:
Quote:
Quote:
Ist es angesichts, dass bereits an einem anderen besseren Downloadsystem gearbeitet, wird überhaupt noch sinnvoll, da am alten was zu ändern? Meiner Meinung nach nur, wenn wenig Aufwand und das aktuelle Verhalten als Default. Last edited by oEFLKQzikCqw; 28.09.2015 at 23:04. |
#28
|
|||
|
|||
@Jiaz: für mich soweit nachvollziehbar und klinke mich erst mal aus. Und... THNX!
Nachtrag: Habe zwei MOCHs die ja auch UL drinnen haben und die vor UP-direkt gesetzt und nun soweit was ich wollte. Last edited by RWeber; 29.09.2015 at 01:05. |
#29
|
||||
|
||||
Quote:
Mirrors: Hier wird der nächste Kandidat gesucht (ReihenFolge/Priorität), dann alle möglichen Mirrors zur selben Datei, und dann von der Auswahl die beste Kombination aus Hoster/Account/Plugin Single: Hier wird der nächste Kandidat gesucht(ReihenFolge/Prioritäten) und dann die beste Kombination aus Hoster/Account/Plugin Quote:
Wenn dem so wäre, dann kann es schnell passieren das nichts lädt, obwohl laden möglich wäre. Zb Link mit hoher Priorität hat Wartezeit, Mirror mit Premium niedrige Priorität. JD wartet somit unnötig und könnte sofort die Datei via Premium-Mirror herunterladen. Quote:
Die Auswahl des nächsten Kandidaten hat nichts mit dem DownloadSystem zu tun. Die derzeitige Implementierung der Auswahl hat als Ziel den Download so automatisiert wie möglich zu machen (also Wartezeit vermeiden, Captchas vermeiden....)
__________________
JD-Dev & Server-Admin |
#30
|
|||
|
|||
Quote:
Quote:
|
#31
|
||||
|
||||
Was ist dann das Problem? Ich kann nicht ganz folgen. Und wie sähe dein Vorschlag aus?
Quote:
UL Free -> Hohe Prio SO Premium -> Low Prio UL/SO sind Mirrors Soll JD jetzt auf UL Free mit hoher Prio warten und zb 1 Stunde nichts tun, weil grad IP Wartezeit obwohl SO sofort mit Premium machbar wäre oder Soll JD auf SO mit Premium ausweichen obwohl UL ne höhere Prio hat. Zweiteres ist derzeit der Fall, damit der Download so automatisiert/schnell wie möglich abläuft
__________________
JD-Dev & Server-Admin |
#32
|
|||
|
|||
Das Problem ist, dass sich JD bezüglich der Prioritäten bei Mirrorlinks nicht so wie vom User erwartet verhält, und somit sein Vorhaben zu Nichte macht. Ganz speziell wird unter Umständen ein Mirrorlink mit niedriger Priorität vorgezogen, weil irgend ein anderer Mirror gerade dran ist und alle anderen Mirror mit höherer Priorität gerade nicht ladbar sind. Ob da andere Links, die normalerweise noch vor dem Mirrorlink möglicherweise ladbar wären, interessiert an dieser Stelle nicht und wird daher auch gar nicht erst geprüft.
JD soll nicht warten und den Mirror mit der niedrigen Priorität erst dann laden, wenn alle Links vor ihm in der regulären Downloadreihenfolge als Downloadkandidaten ausgeschlossen wurden. Das lässt sich erreichen, in dem man die Mirrorlinks bei der Ermittlung der Downloadkandidaten nicht berücksichtigt, Punkt 4 also auslässt. Ja ich weiß, dass man die Mirror trotzdem ermitteln muss, damit die anderen Mirror beim Downloadstart eines Mirrors in den Status Mirror X lädt wechseln. Das muss dann aber erst dann geschehen, wenn man einen Downloadkandidaten gefunden hat. Mir ist gerade ein Workaround für das Problem eingefallen: Die Links vom Mirror mit der niedrigeren Priorität in ein separates Paket am Ender der Downloadliste verschieben. Die Links lassen sich dann auch schneller (de)aktivieren wenn nötig. |
#33
|
||||
|
||||
Aber genau so ist es!
__________________
JD-Dev & Server-Admin |
#34
|
||||
|
||||
Es wird erst der nächste Link gesucht, wobei Reihenfolge und Prioritäten ins Spiel kommen.
Und jetzt wird zu dem nächsten Link alle Mirrors gesucht und davon derjenige Kandidat genutzt der das beste Ergebnis bringt, sprich keine Wartezeit/Captcha/langsamer Speed.
__________________
JD-Dev & Server-Admin |
#35
|
||||
|
||||
Hierauf eine Antwort bitte, denn genau hierauf kommt es am Ende an.
__________________
JD-Dev & Server-Admin |
#36
|
||||
|
||||
Und ich empfinde es nicht als Vorteilhaft/Lösung wenn JDownloader bei einem Download unnötige Wartzeit/Captcha auf sich nimmt, wenn er auch sofort via nen Premium-Mirror ladbar wäre. Und ich gehe einfach mal davon aus die meisten Nutzer wollen das JDownloader so automatisiert wie möglich seinen Dienst richtet und unnötige Wartezeiten/Captchas vermeidet.
Warum man jetzt einen Free-Download mit evtl Wartezeit/Captcha/slow Speed einem Premium-Mirror vorziehen sollte, erschließt sich mir nicht, sorry.
__________________
JD-Dev & Server-Admin |
#37
|
|||
|
|||
Quote:
Quote:
Auf jeden Fall sollte bei aktuellem Verhalten der User gewarnt werden, wenn er bei Mirror-Links unterschiedliche Prioritäten einstellt, dass und warum Prioritäten bei Mirror-Links unter Umständen nicht wie gewünscht funktionieren. Auch die Vorgehensweise beim Ermitteln des nächsten Downloadkandidaten gehört mMn in die Anleitung oder FAQ. Quote:
Du kannnst dir also nicht vorstellen, dass ein User nicht immer den begrenzten Traffik eines Premiumaccounts restlos ausschöpfen will, um für Notfälle gewappnet zu sein? Wartezeiten und Captchas würden da nicht unter Notfall fallen. Ja ich weiß, auch mein Vorschlag kann das nicht sicherstellen, würde aber zumindest das unerwartetes Verhalten beseitigen (Mirrorlinks früher zu laden, als nach Reihenfolge und Priorität bei Unkenntnis der genauen Vorgehensweise zu erwarten wäre). Last edited by oEFLKQzikCqw; 01.10.2015 at 22:09. |
#38
|
||||
|
||||
Was soll JDownloader machen wenn:
1.) der UL Link gerade nicht geht, weil zb Wartezeit, Server Fehler, Download schon läuft -> Warten und auch keinen Mirror anfassen? 1.1.) Was wenn noch ein weiterer Mirror auf Low Priorität steht und ohne Premium, darf der dann auch versucht werden oder wie lange soll auf den UL gewartet werden? 2.) der UL Link gar nicht geht, zb Offline ->Mirror nehmen oder normale Reihenfolge weitermachen? Ich verstehe durchaus den Wunsch auch mal mit Free/Captcha zu laden, weil man eh grad am Rechner sitzt/es nicht *eilig* hat. Die Frage ist nur, wie integriert man diesen Wunsch das alle Fälle auch gut und verständlich abgedeckt sind. Das ganze hat übrigens nichts mit dem Mirrorhandling zu tun! Denn der gleiche Fall ist ja auch wenn ich nen UL Link 1 Free(High) und SO Link 2 Premium(Low) habe. JD versucht erst den UL Link, geht der grad nicht, dann macht er schonmal mit SO weiter. Was du willst ist ein, ich möchte die Priorität beachten, auch wenn ich dann weitere Downloads komplett blockiere. Das Thema ist komplex und wenn ich schon eine gute Lösung gefunden hätte, dann wäre die schon drin Ich bin offen für Vorschläge!
__________________
JD-Dev & Server-Admin |
#39
|
|||
|
|||
Ich würde da keine Unterscheidung zwischen 1. und 2. vornehmen und mit der normalen Reihenfolge weitermachen. Ich will keineswegs weitere Downloads komplett blockieren.
|
#40
|
||||
|
||||
Und was soll JD dann nun machen?
__________________
JD-Dev & Server-Admin |
Thread Tools | |
Display Modes | |
|
|