Neu: Usenet Downloader!

Einen einzelnen Crawljob selbst kannst du über die myjd API nicht einfach deaktivieren, aber das ganzer Folder Watch Addon.
Myjd API Docs:
https://my.jdownloader.org/developers/

Ich bin immer offen für Vorschläge.
Wie gesagt dachte ich zunächst, eine Prüfung auf "Prozent == 100" würde ausreichen, aber scheinbar ja nicht.
Entweder ich baue hardcoded bestimmte Stati ein, die erlaubt sind oder ich baue eine Plugineinstellung, mit der du selbst Stati als Whitelist angeben kannst.

Bitte erstmal mit dem arbeiten was vorhanden ist und dann Feedback geben.

Wie gesagt das ist so nicht vorgesehen.
Dadurch, dass JD open source ist kann man ihn natürlich beliebig für seine Zwecke anpassen.
Link zum Quellcode:
https://support.jdownloader.org/Knowledgebase/Article/View/setup-ide-eclipse

Du könntest es auch ohne crawljob machen und dir stattdessen ein EventScripter Script basteln, das den Link alle X Zeit einfügt.
Das könntest du an die Antwort einer eigenen API koppeln und somit fernsteuern also grobes Beispiel:
"Wenn Ergebnis von Aufruf von URL 'http...meinedomain.tld/jdautocrawl' gleich true dann füge 'https://high-way.me/pages/center/' ein ansonsten nicht".
EventScripter forum thread:
https://board.jdownloader.org/showthread.php?t=70525
EventScripter Hilfeartikel:
https://support.jdownloader.org/Knowledgebase/Article/View/what-is-the-event-scripter

Es gibt auch ein Projekt das es erlaubt, RSS Feeds regelmäßig mit JD einzulesen -> Würde HW diese Daten zusätzlich als RSS Feed bereitstellen, könnte man es auch darüber versuchen. Mehr Infos dazu finden sich in unserem Supportforum.

Wie so oft gibt es viele Wege, ans Ziel zu kommen.

Das würde definitiv funktionieren.
Derzeit rennen die vorab verfügbaren Links in Fehler/"File not found" sprich, JD kann damit nichts anfangen bis sie wirklich ladbar sind bzw. zu .zip Dateien oder Ordnern ("http Directories") mit Dateien führen.
EDIT

Ich habe einen crawljob als Datei an diesen Post angehängt.
(Das ".txt" entfernen dann kann er verwendet werden.)

 

edit 2: Ich habe große Teile dieses Posts geändert, nachdem ich herausgefunden habe, was das Fehlverhalten verursacht.

Ich bin nun endlich mal dazu gekommen das auszuprobieren. Vorerst mal nur manuell, also keine Scripts.

Problem 1: Wenn ich https://high-way.me/pages/usenet/ bzw. https://high-way.me/pages/center/ im JDownloader einfüge, solange die Highway API bei den einzelnen Usenet Downloads noch "zip":"0" meldet (die Downloads aber schon "Completed" sind), bekomme ich korrekt alle Dateien der Usenet Downloads in den Linksammler gelegt und für jeden Usenet Download wird ein Paket erstellt. Sobald die API aber "zip":"1" meldet, funktioniert es nicht mehr richtig. Dann erstellt der JDownloader nur mehr ein Paket mit Namen "Usenet" und darin sind nicht die einzelnen Dateien, sondern für jeden Usenet Download nur eine ".nzb.zip" Datei. Diese Dateien liefern dann aber einen "File not found" Fehler beim Download!

Problem 2: Solange die API noch "zip":"0" meldet, werden Pakete mit einem kryptischen Namen angelegt. Könnte man hier "schöne" Paketnamen erstellen?

Problem 3: Bei Torrents bekomme ich folgendes in den Linksammler gelegt:

• Ein "Torrent" Paket mit ".zip" Links. (Diese funktionieren, es sind die aus den einzelnen Torrent Downloads im Highway Center.)
• Pro Torrent Download im Highway Center noch ein weiteres Paket (mit dem Namen des Torrent-Downloads und einem Unterstrich als Pre- und Suffix), in dem die einzelnen Torrent-Download-Dateien enthalten sind.

Die Torrent Dateien würden also doppelt heruntergeladen werden, sowohl als Zip als auch als einzelne Dateien. Kann man das verbessern, sodass nicht doppelte Downloads im Linksammler landen?

Problem 4: Eine der Dateien in meinen Torrent Downloads heißt "[asdf]asdf asdf.org .txt". Diese Datei führt im JDownloader auch zu einem "File not found" Fehler. Im Highway Center kann ich die Datei aber fehlerfrei herunterladen. Eventuell hat der JDownloader Probleme mit den eckigen Klammern oder dem Leerzeichen vor ".txt"?

 

Puhh hört sich an, als müsste ich hier noch einiges nachbessern.

Bitte mal den debug Modus aktivieren und einen Log bereitstellen siehe:
https://support.jdownloader.org/Kno...ew/47/0/how-to-create-and-upload-session-logs

Wie stelle ich das am besten nach? Brauche ich Torrents zu großen Dateien?

Wie kann ich das nachstellen?
Ansonsten ggf. auch hiervon bitte einen debug-Log bereitstellen.

Man könnte eine Einstellungsmöglichkeit dafür bauen und/oder per default nur entweder zip oder die einzelnen Files einfügen.

Erklärung zu den vielen Paketen und Unterstrichen im Paketname:
https://support.jdownloader.org/Knowledgebase/Article/View/packagizer-adopt-folder-structure

Hierzu bräuchte ich einen Log bzw. Testlinks/Test-Torrents.

Ich vermute, dass das Problem nichts mit den Dateinamen sondern mit dem Response-Header von HW zu tun hat a la "HW Plugin denkt, das sei keine Datei" -> Ohne weitere Infos kann ich da nur mutmaßen


Danke für dein detailiertes Feedback!

 

Zu Problem 1:

Es geht bei Problem 1 und 2 nur um Usenet-Downloads, nicht um Torrents.

Zum Reproduzieren:

1. Einen beliebigen Usenet Download im Highway Center hinzufügen.
2. Warten, bis die API dafür "zip":"1" liefert.
   (Im Highway Center sieht man davon nichts, weder einen Status noch einen Link zu einer ZIP-Datei.)
   
3. https://high-way.me/pages/usenet/ zum JDownloader hinzufügen.
4. Die Downloads starten.

Ich weiß nicht, wann Highway hier die "zip":"1" Änderung in der API macht (im Gegensatz zum Torrent-Bereich finde ich keine Dokumentation zu ZIPs bei Highway-Usenet-Downloads). Aber für mich sieht es so aus, als ob die "zip":"1" Änderung immer ein paar Minuten (ca. 5 bis 30) nach dem "Completed" Status aufscheint. Und das auch bei Usenet-Downloads mit nur 2 Dateien und 500 MB Größe.

JDownloader Debug Log: jdlog://6707311370661

Zu Problem 2:

Relativ einfach, aber leider zeitlich begrenzt:

1. Einen beliebigen Usenet Download im Highway Center hinzufügen.
2. Warten, bis der Download "Completed" ist.
3. https://high-way.me/pages/usenet/ schnell im JDownloader hinzufügen, solange die API noch "zip":"0" zurückgibt.

JDownloader Debug Log: jdlog://7707311370661

Zu Problem 3:

Kann der JDownloader denn unterscheiden zwischen der ZIP-Datei, die Highway erstellt hat, und ZIP-Dateien, die im Torrent-Download selbst enthalten waren?

Zu Problem 4:
JDownloader Debug Log: jdlog://8707311370661
In diesem Log werden 3 txt Dateien heruntergeladen. Alle 3 liefern "File not found", obwohl nur zwei von ihnen die eckigen Klammern und das Leerzeichen vor ".txt" haben. Du hast also recht, es liegt nicht am Dateinamen.

 

Ich lerne und lese immer gerne mit. Aber warum lädt man zu erst im Download Center was runter und gibt es dann später in den JD2?
Einfach NZB im JD2 reicht doch, oder?

 

Siehe Posts #88, #90 und #93 hier in diesem Thread.

 

Problem 1
Entstand dadurch, dass ich im Torrent/Usenet Crawlerplugin eigene Pakete/Paketnamen gesetzt habe.
Das habe ich entfernt -> Auto Handling übernimmt -> Sollte nach dem nächsten CORE-Update passen.

Problem 2
Technisch gesehen ist dies kein Bug:
Wir haben einen generischen Crawler, der besagte "http Directories" crawlen kann.
Die Paketnamen von den "Http Directories" setzen sich aus dem internen Pfad zu den Dateien zusammen.
Dieser ist bei HW "kryptisch".
Beispiel:
https://usenet.dwld.link/dlu/XXXYYY/
-> Screenshot:


Resultierender Paketname (= http-directory-pfad):

Code:

/usenet/phppJC2H2/

Finaler Paketname nach Cleanup:

Code:

_usenet_phppJC2H2_

Um hier sinnvollere Pfade und damit sinnvollere Paketnamen in JD zu erhalten würde ich Yaknar vorschlagen, als internen root-Ordner den Namen der nzb/torrent zu verwenden also in diesem Beispiel:
/usenet/nameVonNzb/unterordner1/unterordner2
Hintergrund zu den Unterstrichen im Paketname:
https://support.jdownloader.org/Knowledgebase/Article/View/packagizer-adopt-folder-structure

Problem 3
Ich habe mir das nochmal angeschaut:
By Design sollten die .zip Dateien nicht hinzugefügt werden, sofern andere lose Dateien vorhanden sind.
Dies scheint nicht (mehr) zu funktionieren.
Die Erkennung der .zip Datei läuft über Pfad + Dateinamensmuster.


Problem 4
Das Problem liegt an den http Headern, die HW zurückgibt.
Ganz simpel beschrieben:
Wenn du so einen Link zu einer Textdatei in deinem Browser öffnest, wird der Text angezeigt.
Ziel ist es aber, dass direkt ein Download initiiert wird.
Dies geht über den Content-Disposition Header, der hier fehlt.

Hintergrund:
Klar könnte JD diese Datei auch so laden - er sieht ja, dass es eine Textdatei ist und laut http-Header Text kommt:

Code:

Content-Type: text/plain

Nur sollte durch stattdessen eine Fehlermeldung kommen, würde JD diese Fehlermeldung als .txt herunterladen. HW muss hier also explizit sagen "achtung hier kommt eine Datei" dann geht das.
Erklärung:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
Da muss Yaknar ran.

 

Danke für die Analyse und die Infos! Problem 1 werde ich dann nach dem Update testen.

Problem 2 ist damit auch erklärt, danke. Jetzt verstehe ich auch, warum ich das bei den Torrent-Downloads noch nicht beobachtet hatte. Dort hatte ich bisher immer Downloads, die noch einen Unterordner erstellt haben, weswegen dann der Unterordner im Paketnamen verwendet wurde.

Ist das vielleicht auch der Grund für Problem 3? In meinen aktuell vorhandenen Torrent-Downloads ist die von Highway erstellte ZIP-Datei direkt im Download-Ordner, alle "originalen" einzelnen Dateien aber in einem Unterordner. Dadurch landen dann eben auch ZIP und einzelne Dateien in eigenen Paketen. Vielleicht erkennt der JDownloader deswegen die einzelnen Dateien nicht und will die ZIP-Datei auch laden?
So sieht der Ordner aus:

 

Ja! Da die .zip Datei im "root Ordner des Torrentdownloads" liegt und der Rest in deinem Beispiel im Unterordner "/Go/..." werden hier technisch-korrekterweise zwei Pakete erstellt.

Problem 3 fixed
Ein falscher/veralteter regulärer Ausdruck hat das zu diesem Bug geführt:
https://github.com/mirror/jdownload...ns/decrypter/HighWayMeFolder.java#L41C3-L41C3
Umgehen kannst du das Problem auch ohne Update, indem du die Domain "dwld.link" in den Torrent Downloadlinks ersetzt durch "high-way.me".
Das Update wird dir auch bereits bessere Paketnamen bringen, da das derzeitige Plugin bereits einige der "Dummy Pfade" (Pfad aus meinem und deinem Screenshot) entfernt bzw. "/torrent/<hash>" wird zu "/" -> Root

 

Problem 2
Mit ziemlich viel Murksen hab ich mich mal daran gemacht, Problem 2 auch im Plugin zu lösen:
Da ich ja über die API den Namen des Torrents/NZB kenne, kann ich mir durch Ersetzungen diesen als neuen Root-Folder nehmen.
Dies wird also die Paketnamen nochmals verbessern, aber nur für Elemente, die via API eingefügt werden.
Die richtige Lösung wäre meiner Meinung nach eine neue/bessere API oder wie schon geschrieben, wenn HW direkt bessere Pfade oben im "Index of ..." stehen hätte.

 

Updates wurden soeben released.
Happy testing.

 

Danke! Testergebnisse für Rev 48149:

Problem 1 tritt leider weiterhin auf. Das Verhalten hat sich geändert, es gibt jetzt ein Paket pro Usenet-Download im Linksammler. In den Paketen ist aber jeweils nur eine ".nzb.zip" Datei und die führt beim Download weiterhin zu einem "File not found" Fehler.

Probleme 2 und 3 sind gefixt, danke!

 

Super!

So seltsam!
Die HW API gibt bei diesen Files "zip":1 zurück was impliziert, dass es sich um eine einzelne .zip Datei handelt.
Ich habe das mal (temporär) so umgebaut, dass der API an dieser Stelle nicht mehr vertraut wird und einfach alle Ergebnisse der API durch den generischen Folder-Crawler gejagt werden.


Das Update bekommst du innerhalb der nächsten paar Minuten.

 

Jetzt ist Problem 1 auch gelöst, danke!

Bleibt nur noch Nr. 4, aber das muss ja auf Seiten von Highway geändert werden. Und das ist auch nicht so schlimm, die txt-Dateien sind meistens eh nicht relevant im Download

 

Ich kann bei Problem 4 natürlich auch noch tricksen, aber ich warte erstmal auf Yaknars Antwort.

 

Hm ok dann hatte ich das Feld bisher falsch genutzt.
Was mir wie schonmal per PN angemerkt helfen würde wäre die Information, ob der Link im Feld "link" zu einer Datei oder zu einem Ordner führt.
So ists auch okay jetzt laufen einfach alle Ergebnisse durch den "http directory Parser" und als Root Folder wird der Name des Torrent/NZB verwendet.

Sehr gut.
Meine Änderungen bringen nur den Usern schönere Paketnamen, die torrent/usenet über "https://high-way.me/pages/usenet/" bzw. "https://high-way.me/pages/torrent/" von JD crawlen lassen.

Valxiron
Ich habe fürs nächste Update noch eine Bubble Notification eingebaut, die erscheint, wenn nichts gefunden wurde oder wenn mindestens 1 Element mit "Prizent niedriger als 100" übersprungen wurde.
Screenshot:

 

Könnten wir bitte eine Möglichkeit bekommen mehrere NZB-Dateien gleichzeitig im Highway Center hochzuladen? Am besten per Mehrfachauswahl im Durchsuchen-Dialog. Oder vielleicht alternativ indem man eine ZIP-Datei mit den NZBs hochlädt.

(Und das gleiche Feature für Torrent Dateien wäre dann auch schön.)

 

Bin auch dafür. Aber: Mach Dir am besten auch gleich mal Gedanken, was bei Fehlern einzelner rauskommen soll.

 

Oh, da hatte ich sogar dafür gestimmt und trotzdem hatte ich es vergessen
Danke!

 

Valxiron
Die folgende Änderung könnte vor allem für dich interessant sein:
Mir ist gestern aufgefallen, dass die WebDAV Struktur von HW auch im Browser aufrufbar ist und dort als Http-Directory präsentiert wird.
Für http-Direcotries haben wir einen generischen Crawler. Ab jetzt lauscht dieser auch auf solche URLs:
https://dav.high-way.me/dav/bla
Ich habe es erstmal absichtlich so gemacht, dass man "/dav/" nicht einfügen kann sondern nur Unterordner davon, aber darüber kann man auch in kurzer Zeit massig Links in JD einfügen.

Beispiele:
Alle [eigenen] TV Aufnahmen:
https://dav.high-way.me/dav/TV/
Alle eigenen Torrent Downloads:
https://dav.high-way.me/dav/Torrent/
Alle eigenen Usenet Downloads:
https://dav.high-way.me/dav/Usenet/

Diese URLs lassen sich nur hinzufügen, wenn man einen aktiven HW Account in JDownloader hat.
Die Downloadpfade werden automatisch gesetzt - derzeit werden sie nicht bereinigt sprich, "/dav/Usenet/" usw bleiben mit drin. Das kann ich bei Bedarf in Zukunft noch anpassen.