HW MOCH Client-Einrichtung JDownloader 2

okay
also der verlinkte thread in Post #243. führt zu einer Account Rules file der gefühlt genauso alt ist wie der von mir erwähnte.

Okay interessant, aber bestimmt könnte man das als Anbieter auch Scripten das die Datei immer selbst erstellt wird und die Grund Settings liefert.

 

Sicherlich - die Möglichkeiten sind grenzenlos.

Auf lange Sicht wäre das Ziel aber, es "richtig" zu machen.
Dies wäre wie folgt:
JD lädt, sofern ein Account verfügbar ist, standardmäßig nur über diesen und niemals im Free-Modus.

Wir haben interne Tickets dazu, aber wann dies umgesetzt wird, bleibt unklar.
Bis dahin müssen die User Verwendungsregeln anlegen, um das Springen in de Freemodus zu vermeiden.

 

Führt mittlerweile eh zu
https://jdownloader.org/jdownloader2

Vielleicht ließe sich der Umweg sparen?

 

Der Link zu einem spezifischen Post im JDownloader Board scheint mir sowieso falsch. Hier wäre eigentlich der richtige Thread: https://board.jdownloader.org/showthread.php?t=54725
Und dort steht auch explizit "Please do not spread these installers over the internet. If you want to link them, please link to this post. Thanks."

 

Toll, ein anderer Umweg! Chapeau Oder übersehe ich was?

 

Die Adware ist eine unserer Einnahmequellen daher bevorzugen wir keine direkten Verlinkungen.
Letztendlich obliegt es euch, welchen Installer ihr bevorzugt.

 

Dann ist doch der "free" Hinweis über Dein Post auf deutsch https://board.jdownloader.org/showpost.php?p=319019&postcount=228
völlig ok so verstehe ich das
Viele Grüße pspzockerscene

 

Klar. Ich hätte eh nicht gemeckert

 

Sers,
in einem Motivationsschub habe ich in letzter Zeit einige Änderungen am CORE von JDownloader vorgenommen.
Es sind größtenteils Änderungen unter der Haube, die man nicht direkt sieht, aber Feedback dazu wäre dennoch interessant.
Ich habe mich dazu entschlossen, nach dem Release größerer Änderungen einen Changelog zu veröffentlichen.
Diesen findet ihr hier:
https://board.jdownloader.org/showthread.php?t=94447

Es gibt den Changelog ausschließlich auf Englisch.
Wer bei Änderungen benachrichtigt werden möchte, kann den besagten Thread abonnieren.

Noch ist der Changelog leer.

 

Sind diese Änderungen schon ausgerollt worden? Ich habe nämlich plötzlich das Problem, dass ich keine Links aus dem Highway Center zu meinem (headless) JDownloader mehr hinzufügen kann. Egal ob ich einen Highway Link (von https://usenet.dwld.link) über das MyJDownloader Browser Addon oder direkt im My JDownloader Web UI über den Button "Links hinzufügen" hinzufüge, der Link taucht dann nie im Linksammler auf.

Eventuell liegt es auch an den Wartungsarbeiten bei Highway heute. Allerdings kann ich die selben Links über den Browser ganz normal herunterladen.

 

Nein siehe Update-FAQ.

Jo evtl. war die HW API down, aber die Webseite nicht.

 

Heute funktioniert es wieder, danke.

 

Yaknar
Nette Statusseite hast du da!
Magst du die HW API als eigenen Punkt hinzufügen oder an der entsprechenden Stelle erwähnen, zu welchem Punkt die API gehört?

 

Mir ist da etwas aufgefallen:
Anwendungsfall 1:
Ich füge einen Download im JDownloader ein, der aus mehreren Parts besteht. Und ich füge auch mehrere Mirrors ein (ein Paket pro Mirror).

Wenn ich mich richtig erinnere, erkennt der JDownloader normalerweise, dass die einzelnen Parts von mehreren Mirrors die selben Dateien sind und lädt sie nur 1x herunter. Wenn es aber ein Hoster ist, der bei Highway zuerst auf die Highway Server geladen wird (mit der Meldung "(x / y MB) Please wait z Sek" im JDownloader), dann startet der JDownloader den Highway-Download für alle Mirrors.
Ich weiß nicht, ob mir dieser Traffic dann schon angerechnet wird. Aber selbst wenn nicht ist das eine unnötige Belastung der Highway-Server, oder?

Möglicherweise ist der Fall schwer zu erkennen bzw. zu behandeln. Aber mir ist noch ein zweiter Fall aufgefallen, der eindeutig sein sollte:
Anwendungsfall 2:
Ich füge einen Download im JDownloader ein, der aus mehreren Parts besteht. Ich füge auch nur einen Mirror ein, also jede Datei nur 1x. Der Download startet, ein paar Dateien werden auch fertig heruntergeladen. Aber nicht alle (z.B. weil der Hoster dann plötzlich Fehler hat). Ich füge nun einen Mirror für die Downloads hinzu.

Auch hier ist es jetzt so, dass der JDownloader den Download auf die Highway-Server für alle Parts startet. Sogar für jene, die lokal bereits fertig heruntergeladen sind. Erst wenn der eigentliche lokale Download starten würde, erscheint die Meldung, dass die Datei bereits existiert.

Kann man das optimieren?

 

Gut zu wissen, danke!

Beim zweiten Download hat der JDownloader auch wieder die "(x / y MB) please wait" Meldung angezeigt. Wenn die Datei bei euch nicht neu geladen werden würde, würde ich das doch nicht sehen, oder?
Ich habe allerdings auch nicht Rapidgator verwendet. Der initiale Download war von Katfile. Der zweite dann von DDownload.

 

Ok, dachte ich mir eh, dass die Highway Server es da schwer haben das zu optimieren.
Aber der JDownloader selbst müsste es doch können. Zumindest im zweiten Fall.

 

Erster Fall:

Jein das kommt drauf an, wie das HW Plugin konfiguriert ist:
Mit Slot blockierendem Handling sollte das eher weniger passieren es sei denn das Cache Handling läuft bei vielen Files komplett durch und ein Download kommt trotzdem nicht zustande.

Mit dem nicht-slot-blockierenden Handling ist jeder erneute "Prüfung" wie ein fehlgeschlagener Downloadversuch -> Es wird ggf. der serverseitige Download aller Mirrors getriggert, da das JD Downloadsystem nur sinngemäß sieht "Mirror 1 geht jetzt gerade nicht -> Versuche Mirror 2 usw usw".
JD wurde niemals mit solchen serverseitigen Downloads im Hinterkopf gebaut daher gibt es dafür kein Spezial-Handling und dies wird vermutlich niemals kommen.
Was du tun kannst, um doppelte serverseitige Downloads zu vermeiden:
- manuell oder per Packagizer Regel die Parts bestimmter Hoster deaktivieren (= Dateien werden als ausgegraut dargestellt in JD), sodass du sie manuell aktivieren musst, wenn dir auffällt, dass Mirror XY nicht geladen werden konnte.
- oder: Immer nur einen Mirror hinzufügen.
- und/oder wenn du Zeit hast: gleichzeitige Downloads in JD runterschrauben und das slot-blockierende Handling verwenden

Zum zweiten Fall:

Tatsächlich ist das was du möchtest möglich.
Hintergrunderklärung:
Es gibt "starke/vertrauenswürdige" und "schwache" Dateimerkmale (Dateigröße, Dateiname usw).
Das Mirror Handling und auch das "Die Datei existiert bereits" Handling möchten bestimmte, möglichst starke Merkmale haben um möglichst zuverlässig entscheiden zu können, was ein Mirror ist bzw. ob eine Datei bereits existiert.
Vereinfacht ausgedrückt wird der finale "sichere" Dateiname in vielen Fällen erst gesetzt, wenn der Download _wirklich_ gestartet wird.
Dies passiert im Falle von HW ggf. erst nach dem Cache Handling.

Hier kommen aber auch wieder mehrere Faktoren zusammen:
Hat der originale Filehoster eine API?
Setzt das Plugin des originalen Filehosters die "finalen" also vertrauenswürdigen Dateinamen/Größen oder nicht?
Beispiel schwache Dateigröße: 1,3MB
Beispiel starke also genaue Dateigröße: 24475 bytes
Habe ich einen starken Dateinamen und die byte-genaue Dateigröße zweier Items mit demselben Dateinamen, kann ich mir auch ohne CRC Hash ziemlich sicher sein, dass es Mirrors sind.
Stellt der Quellhoster einen CRC-Hash zur Verfügung?
CRC Hash verfügbar = bester Fall, denn dann können Mirrors/Duplikate komplett unabhängig von Dateigröße- und Name ermittelt werden (gesetzt dem Fall, dass der Hash korrekt ist, wovon wir ausgehen).
Welche Infos gegeben sind und ob die beim Linkcheck gesetzten Dateinamen schon die finalen / vertrauenswürdigen sind, variiert von Plugin zu Plugin.

Beispiel für ein Plugin, das starke Dateimerkmale bekommt und setzt: drive.google.com
Beispiel für ein Plugin, das lediglich schwache Dateimerkmale bekommt und setzt: rapidgator.net
TL;DR
Um dafür zu sorgen, dass JD für die "Existiert die Datei bereits" Prüfung auch schwache Dateinamen erlaubt und den Check somit ggf. vor Downloadstart ausführen kann, musst du folgende Einstellung anpassen:
Einstellungen -> Profieinstellungen -> GeneralSettings.allowunsafefilenameforfileexistscheck -> Aktivieren
Solange der Name der Datei auf deiner Platte und der Dateiname in JD gleich sind (Groß-Kleinschreibung wird ignoriert) wird das funktionieren.
Für die Erkennung von Mirrors gibt es separate Einstellungen! Dafür in den Einstellungen suchen nach "mirror detection".
Ich rate davon ab, die Mirror Einstellungen zu ändern!

Ein Blick in die mögliche Zukunft (gilt auch für Fall 1):
Verfügbarkeitscheck über Multihoster (sofern dieser das unterstützt):
Der Multihoster kennt die starken Merkmale ggf. bereits vorher und kann sie JDownloader mitteilen, welcher dann mit dem derzeitigen Handling bereits zuverlässiger arbeiten würde.
Auch hier gilt: So einfach ist das nicht und wie soll JD das handhaben - wem soll JD an dieser Stelle mehr vertrauen? Dem Multihoster oder dem original Filehoster?
Beispiele um zu verdeutlichen, warum die Umsetzung komplizierter ist als gedacht:
Multihoster sagt die Datei sei offline, aber original Plugin meint sie wäre online -> Wem vertrauen?
Multihoster gibt einen anderen Hash vor als der Originalhoster, aber dies würde bedeuten, dass der User eine andere Datei bekommt als original erwartet und im schlimmsten Fall z.B. der Entpackvorgang scheitern wird -> Wem vertrauen?

Der Linkcheck wird ausgeführt. Der User hat mehrere Multihoster Accounts eingetragen. Alle dieser Multihoster unterstützen das Feature "Linkcheck per Multihoster" -> Über welchen soll der Linkcheck passieren?
Nur original Plugin? Ein Multihoster? Alle Multihoster? Original Plugin + alle Multihoster?
Welchen Linkcheck-Ergebnis soll vertraut werden?
Zum Linkcheck-Zeitpunkt ist noch völlig unklar, über welchen Hoster der Download am Ende passieren wird.
EDIT

Nachtrag speziell zu Rapidgator: Früher hat RG einen CRC Hash zur Verfügung gestellt. Mittlerweile tun sie dies nicht mehr.

 

Wie immer ist es natürlich komplexer als zuerst gedacht

Aber das:

ist genau das, was ich mir für Fall 2 erwartet habe. Danke!

 

Ja^^
Ich habe nicht immer Zeit / Lust, so eine Wall of Text zu schreiben, aber du schienst bisher auch an Hintergrundinformationen interessiert zu sein daher hier absichtlich die lange Antwort ansonsten einfach direkt zum TL;DR springen.

By the way:
Das Linkcheck über Multihoster Feature würden bisher von allen unterstützten Multihostern 2-3 per API anbieten.

 

Öh schick da gerne ein paar Infos per PN.
Bei uns ist dieser Teil der RG API ("file/info?token=...") auskommentiert mit dem Vermerk, dass der API Aufruf kaputt ist.
Für den Filecheck per API muss man eingeloggt sein, ist das korrekt?