|
|
|
#1
17.01.2023, 19:57
|
||||
|
||||
Frage zu downloadList*.zip und linkcollector*.zip
Sind in jeweils einem der jeweils 5 oder mehr Archive alle Daten komplett vorhanden?
Hintergrund der Frage: Reicht es, jeweils das downloadList*.zip und auch das linkcollector*.zip mit der höchsten Zahl in eine neue Installation zu kopieren, um alle Infos bzgl. heruntergeladener und/oder im LinkGrabber vorhandener Dateien zu transferieren? Oder sind die Infos "verteilt" über die Archive und ich benötige alle? 
|
|
#2
18.01.2023, 12:41
|
||||
|
||||
|
Hallo Stefan,
Quote:
Quote:
Mehr Infos dazu und zur Speicher-Logik dieser Datreien findest du in folgendem Artikel: https://support.jdownloader.org/Know...nkgrabber-list Grüße, psp
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
|
|
#4
18.01.2023, 16:17
|
||||
|
||||
|
@pspzockerscene
hmmmm, leider doch noch ein Problem bzw. eine Nachfrage: Quote:
Nicht aber bei der Downloadliste. :-( Oder muss man das in irgendeiner Form über restore machen? Ich möchte nur die zip-Dateien - also sozusagen die History - mergen aus einem JD, der bis Ende 2022 aktiv war und einem JD, der ab Anfang 2023 genutzt wurde. Drag and Drop in das Download-Fenster wird zwar als "möglich" angezeigt, aber nach dem "Drop" passiert gar nichts. Mit einer anderen zip-Datei probiert... ... da kam die Abfrage und das Importieren scheint damit funktioniert zu haben... Versuche ich Drag and Drop beim Linkgrabber, will er Tausende von Packages importieren, obwohl es unter 200 neue sind, die "on top" hinzuzufügen wären... Oder zählt JD alles und lässt Duplikate am Ende aus? Last edited by StefanM; 18.01.2023 at 16:33.
|
|
#5
19.01.2023, 13:25
|
||||||
|
||||||
|
Quote:
Mergen geht nicht außerhalb von JDownloader sondern nur, indem du während JD läuft mehrere .zip Listenarchive hinzufügst. JDownloader wird dann entsprechend neue .zip Dateien erstellen. Das kann man dann als "merge" bezeichnen. Quote:
(Ebenfalls hier beschrieben.) 1. Drag and drop 2. Datei -> Linkcontainer laden (CTRL + O) Beide sollten die "Importier-Abfrage" zeigen. Ist dies nicht der Fall, hast du evtl. einen Fehler gefunden: Bitte stelle uns einen Log und die downloadlistXXX.zip, die du versucht hast zu importieren zur Verfügung. Sende beides an support@jdownloader.org. Quote:
Bitte stelle uns einen Log und die downloadlistXXX.zip, die du versucht hast zu importieren zur Verfügung. Sende beides an support@jdownloader.org. Quote:
Was mir noch einfällt: Evtl. ist deine Downloadliste sehr groß und deine neue JDownloader Installation läuft in einen "OutOfMemory" Fehler. Bitte poste mal einen Screenshot von "Hilfe -> Über JDownloader" und/oder prüfe wie hier beschrieben, ob JDownloader genügend RAM zur Verfügung steht. EDIT Ich habe den Artikel etwas aktualisiert und bin nochmal extra auf das mergen mehrerer Listen eingegangen.
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
Last edited by pspzockerscene; 19.01.2023 at 13:34. Reason: Tippfehler behoben
|
|
#6
19.01.2023, 17:23
|
||||
|
||||
|
Quote:
Das Einkopieren in den cfg-Ordner hat ja in einem Fall als "Mergen" funktioniert. Drag and Drop hat das für mich etwas merkwürdige Ergebnis gezeigt, dass laut Anzeige (aufgrund der Menge) auch vorhandene Daten neu hinzugefügt werden sollten: In einem etwas anderen Fall als zuvor beschrieben:
Und dabei wurde bei Drag and Drop dann angezeigt, dass - von der Menge her - auch die überlappenden, d.h. doppelten Daten mit importiert werden würden. Aber, so wie ich dich jetzt verstehe, wäre es gemäß URS korrekt, dass diese dann am Ende doppelt vorhanden wären. Das kann ich so natürlich nicht gebrauchen, aber dann muss ich mir anders helfen: z.B. die Daten aus dem Überlappungszeitraum in einer temporären JD-Installation löschen, so dass es keine Duplikate gibt. Und dann dieses "gestrippte" Archiv ins Backup mergen. Das müsste dann ja funktionieren!? Und noch ein Stolperstein, den ich sehe, der aber wohl nicht wirtschaftlich darstellbar entfernt werden kann: Wenn man die Listen merged, dann können ja in einer Installation Links vorhanden sein, die sich noch(!) im LinkGrabber-Fenster befinden. Und in einer anderen Installation können dieselben Links bereits heruntergeladen worden sein. Das dürfte dann ein Chaos geben, wenn man so etwas merged...  Danke nochmals und Gruß Stefan Last edited by StefanM; 19.01.2023 at 17:43.
|
|
#7
19.01.2023, 17:40
|
||||
|
||||
|
Quote:
Quote:
Denn sonst hätte ich ja unerwünschte Duplikate... ... wenn ich es richtig verstehe.
|
|
#8
20.01.2023, 13:30
|
||||||||
|
||||||||
|
Quote:
Egal solange es wie gewünscht funktioniert hat, müssen wir nicht weiter drüber reden. Quote:
Ich habe dies im bereits zuvor verlinkten Artikel durch meine gestrigen Änderungen ebenfalls klargestellt: https://support.jdownloader.org/Know...nkgrabber-list --> Siehe "How to merge multiple linkgrabberlists/downloadlists?" Quote:
Quote:
Ich würde dann wie folgt vorgehen: - Alle links aus Downloadlisten in einen JD 'A' packen - Dann in diesen JDA alle Links aus dem Linkgrabber des anderen JDB (linkcollectorXXX.zip) in den Linkgrabber einfügen und der Linkgrabber von JDA wird dir die Duplikate als "bereits in der Downloadliste" anzeigen Dazu sei gesagt: linkcollectorXXX.zip Dateien lassen sich nur in den Linkgrabber importieren und bei downloadlistXXX.zip Dateien fragt JD dich, ob die Links in Linkgrabber oder Downloadliste landen sollen. Quote:
Quote:
Du musst bedenken, dass dein Fall mal wieder einen Spezialfall ist auf den ich auch im Artikel nicht extra eingehen werde, da es den Artikel aufblähen- und daher unübersichtlich und schwieriger zu verstehen machen würde. Trotzdem nehme ich jederzeit Tipps/Kritik zum Wording von Supportartikeln entgegen. Ich behaupte mal, die meisten User werden einen solchen Wechsel vollziehen, indem sie einfach die Config des alten JD in den neuen umziehen. ...oder sie haben einen alten JD und einen neuen, der nur ein paar Tage verwendet wurde und nur wenige Links enthält und sie ziehen den alten dann später um -> Selbst wenn es Duplikate gibt, wären es nicht viele.
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
|
|
#9
21.01.2023, 13:04
|
||||
|
||||
|
Quote:
Dort steht, dass man - wenn man zwei JD-Installationen mergen möchte - sämtliche downloadlistXXX.zip/linkcollectorXXX.zip von einem in den anderen importieren soll. Dann würde man aber x Duplikate erhalten. Ich darf doch je nur eine downloadlistXXX.zip und nur eine linkcollectorXXX.zip importieren. Zumindest habe ich es so von dir verstanden. Last edited by StefanM; 21.01.2023 at 14:19.
|
|
#10
21.01.2023, 13:14
|
||||
|
||||
|
@pspzockerscene
Eine andere Beobachtung: Ich betreibe JD - wie auch andere PortableApps - auf einer externen HDD. Die downloadList1023437.zip ist ca. 850 MB groß. Die linkcollector157139.zip ist ca. 250 MB groß. Es gibt jeweils 6 Exemplare. Anhand der Zähler erkenne ich, dass die erstere über 1 Mio mal neu erstellt wurde, vielleicht etwas zu oft!?!? Wenn JD ein oder zwei Stunden in Betrieb ist, wird die HDD extrem langsam: Hex-Suche in WinHex als "Messlatte": ca. 2,4 kB/sec statt ca. 113 MB/sec, wenn JD nicht läuft. Ich beobachte das Phänomen schon länger bei verschiedenen externen HDDs, auf die ich jeweils umgezogen bin, weil ich Probleme bei der jeweiligen HDD vermutet hatte. Erst heute habe ich den Verursacher gefunden: JD! JD scheint mit der Größe bzw. der Anzahl der Dateien in den zip-Archiven an eine kritische Grenze gekommen zu sein. Nur müsste man doch über Priorisierungen und/oder andere Einstellungen dieses Ausbremsen der HDD abstellen können. Ich werde dazu ein wenig testen, wäre aber für Input dazu von deiner/eurer Seite dennoch dankbar. Speziell zu Settings im JD... Meine bisherigen Feststellungen bei einem "eingefrorenen" Stand: (und auch Fragen dazu) Über 1,6 Mio Dateien in downloadList*.zip Der Zeitstempel der 6 Archive liegt gut 1 Minute auseinander, also etwas mehr als der Standardwert in DownloadController.maximumsavedelay. Das Erstellen des jeweils upgedateten Archivs dauert vermutlich länger als die eingestellten 60 sec. Möglicherweise sind hier alle Schreibleseköpfe dauerhaft "belegt", was die Ursache der extremen Verlangsamung sein könnte. Kann es hier auch noch zu "Überlappungen" kommen? D.h., dass JD gleichzeitig mehrere Archive (neu) erstellt und/oder downloadList*.zip und linkcollector*.zip auch noch parallel erstellt? Eine Erhöhung der min/max-Werte könnte evtl. helfen. Nur müsste ich dann für die min-Werte deutlich über 60 sec einstellen. Und eine Reduzierung der Dateien in den Archiven würde sicher am ehesten helfen... Weitere Frage/Anregung: In der linkcollector*.zip befinden sich über 400.000 Dateien Im LinkGrabber-Fenster sehe ich nur 500 Dateien, der Rest ist "Already in Download List" Die schleppe ich also unnötig mit. Wäre es nicht sinnvoll, diese zur "Entlastung" regelmäßig (nach einer bestimmten Zeit) automatisch zu bereinigen? An sich benötigt man diese doch in der Regel nicht. Last edited by StefanM; 21.01.2023 at 15:16.
|
|
#11
23.01.2023, 15:59
|
||||||||||
|
||||||||||
|
Quote:
Danke. Ich habe das soeben angepasst. Quote:
Quote:
Quote:
https://support.jdownloader.org/Know...nkgrabber-list Siehe "Downloadlist & LinkGrabber backup settings (advanced settings) and file- saving behavior". Quote:
In jedem Fall ist das ein interessanter "Edge Case". Quote:
Quote:
Quote:
Falls du diese Frage so meinst: Da musst du auf eine Antwort von Jiaz warten dafür müsste ich jetzt im Code nachsehen. Ich denke nicht, dass es sinnvoll ist. Sinnvoll wäre es vor allem, JDownloader und überhaupt alle Anwendungen auf einer SSD laufen zu lassen. Da sich einige Fragen ansammeln, deren Beantwortung Jiaz übernehmen sollte empfehle ich dir, diese konkreten Fragen separat zu notieren, sodass du die beizeig zusammengefasst nochmal hier posten kannst und Jiaz nicht nochmal den kompletten Thread durchlesen muss.
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
|
|
#12
27.01.2023, 16:59
|
|||||
|
|||||
|
Quote:
 Quote:
Nach einem bestimmten Zeitraum mit "Dauer-Schreiben" geht jede SSD in die Kniee, einfach aus Hardware-Schutzgründen. Und JD ist so ein Dauerschreiber. Bei mir hört das Erstellen neuer Archive solange nicht auf, solange JD läuft. 2. (noch wichtiger) Weil das oben genannte zu einem frühen SSD-Tod führt… Quote:
Quote:
Quote:
|
|
#13
27.01.2023, 17:09
|
||||
|
||||
|
@Jiaz
Es geht hier eher um Gedanken zu einer möglichen Optimierung in Bezug auf das Erstellen der Archive. Zurzeit wird ja z.B. jedesmal ein komplett neues Archiv mit allen bisherigen Einträgen zzgl. der hinzugekommenen erstellt. Dies führt ab einer bestimmten Größe zu einem "Dauer-Schreibvorgang", mit zum Teil sehr unglücklichen Folgen. Aber ich habe das Problem durch das Erhöhren des Mindest-Schreibintervalls erstmal abgestellt. Ich erwarte nicht, dass hier eine Änderung erfolgen wird, da es nur Super-User wie mich betrifft. Es gibt aber noch einen sehr unschönen Nebeneffekt, wenn Archive in den sehr kurzen Default-Intervallen immer wieder neu erstellt werden: Das RAM läuft voll, da Windows und auch alle mir bekannten Tools nicht in der Lage sind, nicht mehr benötigte Daten im RAM komplett zu löschen. So sind mir auch 64 GB RAM nach spätestens 24 Stunden "vollgelaufen". Aber auch hier bringt die Erhöhung des Intervalls Abhilfe. Mir ist erst jetzt bewusst geworden, dass JD der Verursacher für das "Volllaufen" ist. Ein Hinweis an die JD-User wäre evtl. sinnvoll. Noch besser eine automatische Anpassung der Intervalle an die zip-Datei-Größen. Oder - noch einfacher - höhere Default-Intervalle. Was spricht dagegen? Hier nochmal die Punkte, die ich an dich senden sollte, separat aufgelistet: Quote:
Quote:
Quote:
|
|
#14
27.01.2023, 17:24
|
||||||
|
||||||
|
Quote:
Mir wäre Geschwindigkeit wichtiger als auf den Verschleiß zu achten, aber jedem das seine. Alternativ könntest du JD in einer RAM-Disk laufen lassen und von dort aus automatisiert alle X Minuten Backups auf eine SSD/HDD schreiben lassen. Dies würde sowohl den JD Start beschleunigen als auch die "Verschleiß Problematik" eliminieren. Quote:
Auch hier muss ich nochmals an Jiaz verweisen. Quote:
Ich möchte auch erwähnen, dass du nicht der erste ist, der die Problematik durch das häufige Speichern der Downloadliste thematisiert hat. Beispiele für ähnliche Threads: https://board.jdownloader.org/showthread.php?t=72045 und: https://board.jdownloader.org/showthread.php?p=423104 Damit zusammenhängendes Ticket: Das Ticket ist seit 2016 offen daher kann ich dir versprechen, dass das ersmal nicht bearbeitet wird und empfehle dir andere Lösungen/Workarounds. Quote:
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
|
|
#15
27.01.2023, 17:48
|
|||||
|
|||||
|
Quote:
Quote:
Quote:
Quote:
Quote:
Beides konnte ich erst jetzt JD zuordnen, obwohl ich mit euch (Du oder Jiaz) auch schon mal generell über das RAM-Vollaufen gesprochen hatte - im Zusammenhang mit der Nutzung von JD... Dass hier das Dauerschreiben von Archiven durch JD der Grund war, habt ihr mir nicht gesagt... 
|
|
#16
27.01.2023, 18:51
|
||||||||||
|
||||||||||
|
Quote:
Ich gehe/ging davon aus, dass JD bei der Verwendung einer SSD eben nicht "dauerschreibt" so wie derzeit (angeblich): Selbst wenn deine Liste 500MB groß ist dürfte sie auf einer SSD in weit unter 60 Sekunden ausgeschrieben sein. Dann sinkt die Schreibauslastung erstmal wieder. Hast du das mal versucht oder ist es einfach eine Annahme von dir, dass du mit SSD (auch) eine dauerhafte Schreibbelastung am Anschlag hast. Quote:
Den schnelleren JD-Start hättest du dennoch als Vorteil. Falls du JD jedoch nur einmal startest und er dann sehr lange läuft, dürfte die dei Startzeit wohl egal sein. Quote:
Quote:
Als Poweruser wirst du bei vielen Softwareprojekten an Grenzen stoßen und/oder Bugs finden, die nur beim Erreichen dieser "Grenzen" auftreten. Quote:
Dasselbe passiert auch z.B., wenn ein Videoschnittprogramm am Rendern ist. Quote:
Du musst JD ja nicht deinen ganzen RAM zur Verfügung stellen. Wie viel RAM du der JD JVM geben magst, entscheidest du selbst mit den .vmoptions Parametern siehe: https://support.jdownloader.org/Know...vmoptions-file Quote:
JD war nie mit dem Hintergedanken konzipiert, dass man millionen von Links in die Downloadliste wirft oder diese als Download-History verwendet. Wir haben in vergangenen Threads bereits beschrieben, welche Ausmaße an Umbau notwendig wären, sodass JD große Listen besser handhaben würde. Quote:
Das ist noch mmer eine Annahme von dir, die nicht bestätigt wurde daher gab es auch keinen Grund / Situation, in der wir dir das hätten sagen sollen. Gibt es einen bestimmten Thread, in dem du eine solche Antwort von uns erwartet hättest?
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
|
|
#17
28.01.2023, 14:39
|
||||
|
||||
|
Ich schreibe zuviel, da wird immer nur ein Teil gelesen… :(
Daher die Themen nun in separaten Posts: Beim "Vollaufen" des RAMs meine ich nicht den z.B. mit Xmx4g auf 4 GB eingestellten Wert. Quote:
Es geht darum, dass leider auch in Windows 11 belegter Speicher nicht wieder voll freigegeben wird: Summiert man die Speicherbelegungen aller laufenden Programme - z.B. aus dem Taskmanager - auf, so ist die Summe direkt nach einem PC-Neustart etwa gleich dem insgesamt belegten Speicher. Nach einigen Stunden Betrieb kann der insgesamt belegte Speicher schon bis zu 2 x so groß sein. JD ist hier besonders problematisch, wenn tatsächlich (meine frühere Einstellung) spätestens alle 60 Sekunden ein neues Archiv mit 1,5 Mio Einträgen und 850 MB erstellt wird. Da laufen selbst 64 GB schon nach wenigen Stunden komplett voll. Das meinte ich. Und auch das kann ich durch Erhöhen des Mindestintervalls auf 30 Minuten deutlich entschärfen. Das schnelle "Volllaufen" scheint auch mit der Art zusammenzuhängen, wie die zip-Archive erstellt werden. Ist halt nicht für Power-User gedacht. Und beim Zippen werden wohl auch nicht alle Prozessorkerne genutzt wie z.B. bei WinRar.
|
|
#18
28.01.2023, 15:00
|
||||
|
||||
|
Teil 2 zum "Volllaufen" des RAMs
Quote:
Ich muss jetzt aber doch nicht beweisen, dass ich mit euch schon mal darüber gesprochen habe!? Konkret hatte ich damals - für mich damals neu - die Infos zum Einstellen des Wertes über Xmx4g von dir oder Jiaz erhalten. Hatte aber damals schon gesagt, dass das nicht hilft gegen das Volllaufen. Wenn ich den Thread zufällig finde, nenne ich ihn dir.
|
|
#19
30.01.2023, 12:43
|
||||
|
||||
|
Quote:
Zurück zum eigentlichen Thema: Hast du das Intervall, in dem die Downloadliste erstellt wird nun geändert? Falls ja: Resultat? Quote:
Nochmal präziser: Es gab aus meiner Sicht keine Stelle, an der wir das "Downloadliste wird noch geschrieben, wenn Intervall vorbei" Problem hätten sehen können- und dir die RAM Belastung dadurch hätten prophezeihen können". Wenn überhaupt, kann nur Jiaz weitere Infos zu diesem Thema beisteuern.
__________________
JD Supporter, Plugin Dev. & Community Manager
JDownloader 2 Setup Download
Spoiler:
A users' JD crashes and the first thing to ask is: Quote:
Quote:
|
|
#20
30.01.2023, 19:00
|
||||
|
||||
|
Quote:
Resultat - wie geschrieben - Problem gelöst.  Ich lasse dir wenn es geht schon morgen eine Downloadliste zum Testen zukommen. Würde ich auf WeTransfer hochladen. Dauert bei 850 GB bei mir bestimmt mind. 2 - 3 Stunden. Den Link sende ich dann an eure Support-Adresse?
|
 |
| Thread Tools | |
| Display Modes | |
|
|
Hybrid Mode
