[sj_rolak]

moin zusammen,

einige (gefühlte) Unstimmigkeiten bis Lästigkeiten, aufgefallen in der letzten Zeit:

Wenn via '<rechts>/Archiv(e)/Archivpasswort setzen' für ein Paket das zu nutzende Passwort vorgegeben wird, bleiben die aus welchem Grund auch immer für sinnvoll gehaltenen von JD ermittelten Passwörter erhalten (inkl solch toller Vorschläge wie 'autopost' oder 'filecrypt.cc'). Kostet zwar kaum etwas, doch das PasswortSuchen beim Entpacken fiele weg und es ist nur noch das richtige pw zu sehen, falls es ermittelt werden soll.
Zwischenzeitlich waren die Vorgaben für SJ-Pakete verschwunden, sehr entgegenkommend, doch leider nicht dauerhaft.

Wenn im Linksammler via '<rechts>/mehr/in neues Paket verschieben' gewählt wird, ist zur Eingabe des neuen Namens vorab ein <TAB> bzw click notwendig - im Gegensatz zB zur EingabeMaske fürs PasswortSetzen. Tausende von Paketnamen ins Nirvana getippt
Im Zuge eines der letzten updates scheint es endlich gelungen zu sein, konsequent das umbenannte bzw neue Paket markiert zu hinterlassen, sehr schön. Nur wenn es (was immer wieder mal vorkommt) wg was auch immer für einen Moment aus der Anzeige verschwindet um nach vollzogener Bearbeitung wieder aufzutauchen - in dem Fall hat zwischenzeitlich ein anderes noch auf Komplettierung wartendes Paket die Markierung geerbt, ärgerlich für ein im SammelRhythmus ohne Überprüfung geklicktes 'Auswahl in DL-Liste übernehmen'.

Ebenfalls im Zuge eines der letzten updates haben Teile des Linksammlers ihre Fähigkeit zum DateigrößenZählen verloren, Zusammenfassung geht noch, PaketZeile nicht mehr (Schnappschuss).
Schon wesentlich länger besteht eine Inkonsistenz zwischen den PaketGrößen-Angaben im DownloadTab: Die Paketzeile zeigt die tatsächliche Paketgröße an, die Zusammenfassung die Summe aller partGrößen jedes hosters (Schnappschuss).

'DownloadTab/<rechts>/Einstellungen/Umbenennen' kreuzt das 'Unterordner nach Paketname' (D:\bulk_dl\<jd:packagename>) aus, muß jedesmal gefixt werden. '<rechts>/mehr/in neues Paket verschieben' würde das vermeiden, sortiert das Paket allerdings am Ende der Liste ein, was je nach deren Umfang ein wenig aufwendiger zu korrigieren ist.

Ein generelles 'falls reconnect zugelassen, nach jedem beendeten freeDL sofort reconnect' wäre schön, würde einige unnötige Wartezeiten abwenden - geht vielleicht über ein eventscript, mal schauen...

Eher richtig unangenehm ist ein Verhalten der Haltemarke: Falls mindestens ein part der Pakete vor der Marke gerade nicht abgearbeitet werden kann (zB wg vom hoster zur premiumWerbung vorgesehener Wartezeit), werden auch die Pakete hinter der Marke in Angriff genommen, was zu Problemen mit mengenlimitierten accounts führen kann (bei SO zB droht ein drastisches Wochenlimit).
Daher laufen hier in Zeiten des freeDL zwei Instanzen des JDL, eine nur für free -- was eine weitere kleine Lästigkeit mit sich bringt: Mir hat sich noch keine Systematik erschlossen, welcher von beiden die Click'n'Load-Pakete annimmt. Da wäre ein Schalterchen "Click'n'Load von dieser Instanz verarbeitet" hilfreich.
Doch eine totale Lösung ist das Doppeln nicht, da auch 'temporäre server-Probleme' die Haltemarke umgehen lassen.

btw: Sporadisch öffnet JDL einen browserTab zur UploadedBewerbung, ist ja ganz ok, doch wurde irgendwo mal erklärt, wie das abgestellt werden kann - wurde auch gemacht. Ist allerdings nach einem update wieder an gewesen (ist auch ok, solange es wieder abgestellt werden kann) und das 'wie' der Behebung war vergessen. Hab mir gerade einen Wolf gesucht und nichts gefunden außer der Abschaltung des Banners. Stellt das das browserPopup direkt mit ab oder fehlt da noch was?

[sj_rolak]

Ebenfalls im Zuge eines der letzten updates haben Teile des Linksammlers ihre Fähigkeit zum DateigrößenZählen verloren, Zusammenfassung geht noch, PaketZeile nicht mehr (Schnappschuss).

Dieser Punkt ist mit dem eben eingespielten update repariert worden.

[sj_rolak]

Stellt das das browserPopup direkt mit ab?

While waiting schon mal weiter mit Eigenbeantwortung: Anscheinend ja, denn zwischenzeitlich ploppte kein browserFenster auf.

Dafür kam über die letzte Nacht via update ein neuer Blinker hinzu: Ein AufmerksamkeitsHeischen bei ausgeschalteter clipboard-Überwachung. Änderbar mit

Advanced setting: GraphicalUserInterfaceSettings: Clipboard Disabled Warning Flash (auskreuzen)

Ein neues, zumindest neu wahrgenommenes Problemchen: ShareLinks.biz hängt in der CloudFlare und ein Zugriffsversuch wird daher ab+zu mit einem "checking your browser before accessing... (ddos prevention)" quittiert und mit hinter der domain gekappter url abgestraft. Beim zweiten Aufruf aus dem browser dringt dann die OrdnerNummer durch.
Nun gibt es ja durchaus auch Ordner ohne das Angebot eines Containers bzw Click'n'Load (**External links are only visible to Support Staff**Beispiel) - und offensichtlich verwirrt das wolkige Intermezzo JD nachhaltig, kommt doch bestenfalls (manchmal auch garnichts) ein Teil des Gewünschten an:361 links einzeln durchkopieren ist Strafarbeit :/

[pspzockerscene]

Cloudflare für sharelinks eingebaut ...
---

[Please read]=>How/when do I get updates?
Read it carefully BEFORE complaining that something would still be not working!
Update cycles depend on your installed JD version!!

---
[Bitte lesen]=>Wie/wann bekomme ich Updates?
Bitte vollständig lesen bevor ihr euch beschwert, dass etwas immernoch nicht funktionieren würde!
Die Updatezyklen variieren je nach installierter JD Version!!

GreeZ pspzockerscene

[sj_rolak]

eingebaut

Oh wie schön ist Panama, pspzockerscene, herzlichen Dank, dann erwarte ich hoffnungsfroh zur einfachen Kollekte (gut, daß stur ausgesessen...) das erlösende Blinken des AktualisierungsIcons.

[pspzockerscene]

Originally Posted by sj_rolak

das erlösende Blinken des AktualisierungsIcons.

Reine Plugin Updates werden ohne "Blinken des Updateicons" ausgeführt - da muss ich dich enttäuschen:w00t::w00t:

Grüße, psp

[sj_rolak]

ohne

Uii, geheime Untergrundkanäle^^ dann wird halt sporadisch getestet, eben gings immerhin schon bis 123/361.

[sj_rolak]

da muss ich dich enttäuschen

Entgegen Deiner Ankündigung klappte das mit CloudFlare/C'n'L mittlerweile hervorragend, **External links are only visible to Support Staff**.... Besser gehts nicht.

[User feedback required]

War das das Gewünschte?
In der anderen Richtung fehlen mir noch ein wenig die Reaktionen zu allen nicht hier schon als bereits gelöst angebenen Problemchen...

[Jiaz]

Fixed, auf PluginUpdate warten

[sj_rolak]

Schon wesentlich länger besteht eine Inkonsistenz zwischen den PaketGrößen-Angaben im DownloadTab: Die Paketzeile zeigt die tatsächliche Paketgröße an, die Zusammenfassung die Summe aller partGrößen jedes hosters (Schnappschuss).

Das ist zwischenzeitlich gelöst worden.

[sj_rolak]

Originally Posted by sj_rolak

{1.11.2015}
Wenn im Linksammler via '<rechts>/mehr/in neues Paket verschieben' gewählt wird, ist zur Eingabe des neuen Namens vorab ein <TAB> bzw click notwendig - im Gegensatz zB zur EingabeMaske fürs PasswortSetzen. Tausende von Paketnamen ins Nirvana getippt;)

Was lange währt, wird endlich gut: statt des verflixten siebten Jahres nun doch erfreulicherweise gefixt nach sieben Jahren. Thx!

[pspzockerscene]

Danke fürs Feedback.

Ich nehme an andere in diesem Thread angeführte Punkte bleiben noch immer offen?

[sj_rolak]

Originally Posted by pspzockerscene

noch immer offen?

Hmm, mal der Reihe nach:

PasswortSuchen beim Entpacken

Es sammeln sich in der Passwortliste immer noch (zwischenzeitlich genutzte?) Passwörter, doch mittlerweile schmeiß ich die dann&wann einfach raus - allerdings eher aus formalen Gründen, viel Zeit benötigt die durchgeführte Suche nun wirklich nicht. Ulkige Vorschläge (filecrypt etc) nach Quelle kommen immer noch, stören jedoch nicht, weil eh via ^v das gebufferte pw eingegeben wird.

auf Komplettierung wartend

So einen 'gewählt'-Markierungs-Verlust habe ich ewig nicht mehr gesehen, kann selbstverständlich auch ein Artefakt des damaligen RechnerSystem bei Auslastung gewesen sein...

kreuzt das 'Unterordner nach Paketname' (..) aus

kann ich zur Zeit nicht nachvollziehen, wird auf die Beobachtungsliste gesetzt.

nach jedem beendeten freeDL sofort reconnect

Nie mehr benötigt, da eh fast immer ein captcha interaktiv gelöst werden muß, da die ~Automatiken dysfunktional (geworden) sind. Dann stört alle wasauchimmer zu klickernde 'reconnect' auch nicht mehr.

Verhalten der Haltemarke

ist unverändert (zumindest letzten Monat noch einmal). Allerdings sind Ausbrüche sehr selten geworden, ewig große DL-Listen ebenfalls.


Zusammenfassung: selbst wenn irgendetwas noch unter dem Niveau 'golden' ist, ists eher problemlos. Gute Arbeit wie seit Jahren schon!

[Jiaz]

Originally Posted by sj_rolak

Es sammeln sich in der Passwortliste immer noch (zwischenzeitlich genutzte?)

In die Passwortliste werden nur erfolgreiche Passwörter aufgenommen, sprich Passwörter welche durch einen Entpackvorgang *bestätigt* wurden. JDownloader sortiert die Liste ebenfalls selbstständig, damit die zuletzt genutzten Passwörter immer am Anfang der Liste stehen.

[Jiaz]

Originally Posted by sj_rolak

Was lange währt, wird endlich gut: statt des verflixten siebten Jahres nun doch erfreulicherweise gefixt nach sieben Jahren. Thx!

Ich hatte letztens eine entsprechende Anfrage und gerade ein paar Minuten Zeit und dachte mir *sooo schwer* kann das nicht sein...Pustekuchen..aber dann doch eine funktionierende/brauchbare Lösung gefunden

[pspzockerscene]

Originally Posted by sj_rolak

Zusammenfassung: selbst wenn irgendetwas noch unter dem Niveau 'golden' ist, ists eher problemlos. Gute Arbeit wie seit Jahren schon!

Danke für das nette Feedback!

[sj_rolak]

Originally Posted by Jiaz

nur erfolgreiche Passwörter

Das mit dem 'genutzt' war einerseits von mir zu unpräzise formuliert - und andererseits trotzdem von identischer Aussage. Sind doch seit Jahren dank der glorreichen Erfindung von c/p bzw KeyMakro die einzigen unbekannten Passwörter diejenigen Ausnahme-PWs, die vergessen wurden einzugeben - klassischer Flüchtigkeitsfehler, und eindeutig meinerseits.

Originally Posted by Jiaz

*sooo schwer* kann das nicht sein

Tja, dies und 'kannste mal eben' dürften die allerschwierigsten Vorgaben sein;)

[pspzockerscene]

Läppische ~7 Jahre später beantworte ich hiermit weitere Teile deines Eingangsposts :D

Originally Posted by sj_rolak

Eher richtig unangenehm ist ein Verhalten der Haltemarke: Falls mindestens ein part der Pakete vor der Marke gerade nicht abgearbeitet werden kann (zB wg vom hoster zur premiumWerbung vorgesehener Wartezeit), werden auch die Pakete hinter der Marke in Angriff genommen, was zu Problemen mit mengenlimitierten accounts führen kann (bei SO zB droht ein drastisches Wochenlimit).

Besteht die Problematik denn noch immer?
Mir würde jetzt nicht einfallen, wie sich das Problem lösen lassen könnte.
Statt der Stoppmarke könntest du auch einfach den "Stop downloads but finish running ones" Button nutzen. Das würde zumindest gehen sofern du vorher schon alle Downloads starten kannst, die vor dem Stopp noch durchlaufen sollen.

Originally Posted by sj_rolak

Daher laufen hier in Zeiten des freeDL zwei Instanzen des JDL, eine nur für free -- was eine weitere kleine Lästigkeit mit sich bringt: Mir hat sich noch keine Systematik erschlossen, welcher von beiden die Click'n'Load-Pakete annimmt. Da wäre ein Schalterchen "Click'n'Load von dieser Instanz verarbeitet" hilfreich.

Dafür habe ich keine gute Antwort/Lösung.
Standardmäßig kannst du gar keine zwei JD Instanzen gleichzeitig laufen lassen und auch wenn das möglich ist, ist das nicht so gedacht.
Die "falsche Verwendung" führt also erst zu diesem Problem.
Im Zweifel könnten entsprechende EventScripter Scripte Abhilfe deiner Problemstellungen schaffen.

Originally Posted by sj_rolak

btw: Sporadisch öffnet JDL einen browserTab zur UploadedBewerbung, ist ja ganz ok, doch wurde irgendwo mal erklärt, wie das abgestellt werden kann - wurde auch gemacht.

Dazu haben wir mittlerweile einen Supportartikel:
https://support.jdownloader.org/Know...tribute-button

Grüße, psp
EDIT

Ich möchte eben noch anmerken, dass ein anderer User gerade ebenfalls einen Thread bzlg. Funktionalität der Haltemarke eröffnet hat evtl. ist das für dich auch interessant: Klick

[sj_rolak]

moin pspzockerscene, läppische fast-7-Tage später die instantane Antwort:

"Stop downloads but finish running ones"

nice hack, müßtet ihr mir allerdings in knatschrot und 99p groß quer übers Fenster schreiben, was im Werkzeugleisten-Werkzeugkasten noch alles drin ist
Mich verwundert bei 'kein DL-Start mehr, wenn alle DLs bis zu dieser Marke abgearbeitet sind' die imho unnötig komplexe Logik - 'kein DL-Start unterhalb dieser Marke' würde es ebenfalls tun, immerhin sind die Linklisten doch geordnet (sonst ließen sie sich ja nicht umsortieren).

btw Sortierung: falls irgendwem für zB Weihnachten noch ne Idee für ein Superluxus-Extra-Goodie als Spezialprojekt fehlen sollte, eine hätte ich noch. Denn heute morgen fiel nach dem Ergrabbeln ua **External links are only visible to Support Staff**jener Alben wieder mal auf, wie supergeschmeidig es doch wäre, wenn die in korrekter Reihenfolge ergrabbelten Einzeltracks auch klick-automagisch durchnummeriert werden könnten in die Richtung

01 - Spoonfull.mp3 {alles bereits YT-meta-befreit und konvertiert}
02 - Brainkiller.mp3
03 - Dogs of War.mp3
...

zwei JD Instanzen gleichzeitig laufen

Vorab: das war eine damalige Zwischenlösung wg ausufernd großer Dokusammlung im free+Captcha-Spektrum zu Zeiten, als Captcha-fremdlösen-lassen noch möglich war und ist längst obsolet.
Nee, die liefen nicht gleichzeitig, JDL war nur zweimal installiert und die Erstgeburt (oder wars die letzte Instanz?, lang her, jedenfalls eine der installierten) riss die Bearbeitung der Click'n'Load-Anfragen an sich. Diese Klippe ließ sich aber durch DLC-erstellen/importieren lässig umschiffen.

mittlerweile einen Supportartikel

Da gefällt mir Option #1 am besten - allerdings ging es damals nicht um den JDL-Tab, sondern um von JDL im StandardBrowser geöffnete Tabs mit 1CH-Werbung ua jedesmal, wenn zum Fensterwechsel aus Versehen in den freien Raum rechts der Werkzeugleiste geklickt wurde.
Das damals durch Rechnerwechsel entstandene Problemchen wurde wg erfolgloser MenuSichtung dadurch beseitigt, daß die letzte Installation, in der dieser Effekt erfolgreich ausgeschaltet worden war, reinkarniert und via updates bis heute durchgepflegt wurde.

ein anderer User gerade ebenfalls

Neckisch, auch wenn mir während des ganzen Tippens noch keine sinnvolle Anwendung dafür eingefallen ist, doch was weiß ich schon...
Jedenfalls gehts da um ein umschaltbares Verhalten - und sowas ist von user-Seite her klar akzeptabel. Solange was Neues nicht was geliebtes Altes vom Sofa schubst, ist alles im grünen Bereich.

[pspzockerscene]

Originally Posted by sj_rolak

Mich verwundert bei 'kein DL-Start mehr, wenn alle DLs bis zu dieser Marke abgearbeitet sind' die imho unnötig komplexe Logik - 'kein DL-Start unterhalb dieser Marke' würde es ebenfalls tun, immerhin sind die Linklisten doch geordnet (sonst ließen sie sich ja nicht umsortieren).

Natürlich könnte man die Logik ändern, aber ich behaupte, du verstehst diese noch nicht ganz oder denkst sie wäre fehlerbehaftet:
Es dürfen ja auch Downloads "unterhalb" der Marke geladen werden, aber es werden keine neuen gestartet sobald das File mit der Marke versucht- oder erfolgreich heruntergeladen wurde.
Ein ähnliches Beispiel hatten wir auch im anderen Thread:
- Du hast 10 Links in JD: 5x rapidgator, 5x 1fichier in dieser Reihenfolge
- Du erlaubst 5 gleichzeitige Downloads und setzt die Haltemarke auf File Nummer 4 von rapidgator (RG erlaubt max 1 gl. DL als Freeuser)

Was nun passieren wird:
- Der erste RG download startet
- Der erste 1fichier Link UNTER dem RG Link mit der Haltemarke startet
- Das geht weiter, solange die Stoppmarke nicht erreicht wird. Es kann also gut sein, dass die 1fichier Links allesamt vor den RG Downloads und damit vor der Stoppmarke fertig werden, obwohl sie sich in der Liste "unter" der Stoppmarke befinden.

Was du gerne hättest(?):
- Alle RG Links werden nacheinander geladen bis zur Stoppmarke und danach wird gestoppt

Originally Posted by sj_rolak

ua jener Alben wieder mal auf, wie supergeschmeidig es doch wäre, wenn die in korrekter Reihenfolge ergrabbelten Einzeltracks auch klick-automagisch durchnummeriert werden könnten in die Richtung

Es gibt keine garantierte Reihenfolge in der gecrawlte Links in JD landen, aber wenn es dir um die Tracknummern in Filenames geht: Das ist bereits möglich.
Siehe Einstellungen -> Plugins -> YT -> Runterscrollen und du kannst benutzerdefinierte Dateinamen einstellen.
Das du möchtest wird *PLAYLIST_POSITION* sein.

Originally Posted by sj_rolak

Jedenfalls gehts da um ein umschaltbares Verhalten - und sowas ist von user-Seite her klar akzeptabel. Solange was Neues nicht was geliebtes Altes vom Sofa schubst, ist alles im grünen Bereich.

Darum geht es dir ja auch, da du ein anderes Verhalten der Haltemarke als sinnvoller erachten würdest.

[sj_rolak]

Originally Posted by pspzockerscene

*PLAYLIST_POSITION*

Mist, daß dergleichen (in welcher Form letztlich auch immer) bereits einbaut sein könnte, wurde hier überhaupt nicht in Erwägung gezogen und die Eingebung ohne nachzuschauen vorgetragen - sorry für die blöde Frage und danke für den Hinweis.

Haltemarke

(Zufallsfund bei Hilfesuche)
Mal grundlegend angefangen: Welche 'bis hierhin und nicht weiter'-Szenarien halte ich denn so für sinnvoll?

1. nur Dateien bis genau hier
2. nicht übers AccountLimit hinaus zu laden versuchen
3. nur bis zu einer gewissen Uhrzeit
4. auf jeden Fall ?GiB Zielplatte frei lassen

Dabei scheinen mir die Punkte 2-3 eher Kandidaten für das Haltemarken-Verhalten modulierende Randbedingungen zu sein und wie auch Punkt 4 mehr für die allgemeinen DL-Einstellungen sinnvoll.
Zusätzlich soll der DL gemäß der in Einstellungen/Allgemein/Downloadverwaltung eingetragenen Vorgaben ablaufen (an die sich 'Start erzwingen' naturgemäß nicht hält). Aktuell sieht der Anfang der LinkListe hier folgendermaßen aus, 1F der PremiumAccount, Rest free:Zuoberst die noch nicht geladenen Pakete; dann die noch nicht einlager-fertigen Pakete (Episoden-Umbenennung, proof- und sonstige nicht benötigte Teile entsorgen); dann die fertigen Pakete neuer Serien; dann die fertigen Pakete die bereits Vorhandenes ergänzen. Die letzten beiden Gruppen jeweils alphanumerisch sortiert, die erste nach Paketname, die zweite nach #ArchivZielplatte|Paketname und beide Gruppen werden kleiner, wenn die betroffenen Pakete vom Rechner ins Archiv verschoben sind.

Fast alle von alleine durchlaufenden DLs, ob nun erkauft, Mediathek oder Mega etc, werden gestartet, wenn ich die nächste Zeit nicht vor dem Monitor sitzen werde (Arbeit, Einkaufen, Tiefschlaf, ...), insbesondere bei größeren Volumina, sagen wir mal zweistellig GiB. Und genau dann soll JDL die Finger von allem lassen, was in jener Sitzung nicht heruntergeladen werden soll. Also weder irgendetwas nur mit meiner Hilfe Ablaufendes noch irgendetwas AccountStrafen nach sich Ziehendes starten. Doch genau das geschieht (ok: kann geschehen), wenn noch nicht Heruntergeladenes irgendwo weiter unten in der Linksammlung angesiedelt ist und auch nur bei einer einzigen abzuarbeitenden DL-Datei gerade der server nicht läuft oder was auch immer sonst den erfolgreichen DL-Abschluss verhindert.

"The Patient" (wie hübsch doppeldeutig;)) kann auch nicht einfach mal eben deaktiviert und später wieder aktiviert werden, da er einige bereits deaktivierte NotfallZusatzLinks bevorratet, deren Zustand danach wieder restauriert werden müßte.

Sehr neugierig wäre ich übrigens auf ein Beispiel, das die aktuelle Haltemarken-Logik zwingend benötigt - das länglich von Dir vorgetragene RG/1F-Beispiel zum Normalverhalten der Haltemarke ist jedenfalls keines. Außerdem werden auch in dieser Situation Pakete angepackt werden, die den 10 Links folgen, solange nicht alle RG-Dateien angekommen sind. (Dein "Du hast 10 Links in JD" unterscheidet sich ja ziemlich von "Du hast genau 10 Links in JD")

[pspzockerscene]

Originally Posted by sj_rolak

Mist, daß dergleichen (in welcher Form letztlich auch immer) bereits einbaut sein könnte, wurde hier überhaupt nicht in Erwägung gezogen und die Eingebung ohne nachzuschauen vorgetragen - sorry für die blöde Frage und danke für den Hinweis.

Gerne.

Originally Posted by sj_rolak

(Zufallsfund bei Hilfesuche)

Was ist der Grund dieser Verlinkung?
In dem von dir erwähnten Thread geht es ebenfalls darum, dass ein User die Funktionalität der Haltemarke nicht versteht bzw. der verlinkte Thread scheint mir eher ein Kommunikationsproblem zwischen dem User und uns gewesen zu sein zudem hatte sich der User irgendwann nicht mehr gemeldet.

Originally Posted by sj_rolak

Mal grundlegend angefangen: Welche 'bis hierhin und nicht weiter'-Szenarien halte ich denn so für sinnvoll?

Du beziehst dich auf die Stoppmarke bzw. hättest gerne andere Modi der Stoppmarke, sodass du das Verhalten dieser personalisieren kannst?

Originally Posted by sj_rolak

nur Dateien bis genau hier

Ich weiß nicht wie es intern aussieht, aber och kann mir vorstellen, dass das umsetzbar ist.

Originally Posted by sj_rolak

nicht übers AccountLimit hinaus zu laden versuchen

Das sollte JD sowieso nicht.
Bitte genauer ausführen.

Originally Posted by sj_rolak

nur bis zu einer gewissen Uhrzeit

Stoppmarken-Kontext mal außer acht gelassen, ist das bereits möglich:
Einstellungen -> Erweiterungen -> Zeitplaner -> Installieren und JD neustarten und dann siehe Einstellungen -> Zeitplaner

Originally Posted by sj_rolak

auf jeden Fall ?GiB Zielplatte frei lassen

Macht JD bereits.
Den Wert kannst du beliebig ändern siehe Einstellungen -> Profieinstellungen -> GeneralSettings.forcedfreespaceondisk

Originally Posted by sj_rolak

Und genau dann soll JDL die Finger von allem lassen, was in jener Sitzung nicht heruntergeladen werden soll. Also weder irgendetwas nur mit meiner Hilfe Ablaufendes...

Captchas vermeiden geht mit einem Button-Klick, indem du den "Ruhemodus" aktivierst.
Diesen findest du in der oberen Toolbar: Symbol mit einem Fenster und einem roten X darüber als Checkbox Element.

Ich kann deiner Ausführung auch mit dem Screenshot leider nicht folgen.
Es wäre für mich hilfreicher, wenn du nochmal kurz in Worte fassen würdest, welches Stoppmarkenverhalten du in deinem Beispiel gerne hättest bzw. welches "unerwartetes"- oder "nicht sinnvolles" Verhalten derzeit vorliegt.
Genauer:
- Was wird geladen und sollte nicht geladen werden?
- Wann möchtest du, dass gestoppt wird und wann wird derzeit gestoppt?

Originally Posted by sj_rolak

...kann auch nicht einfach mal eben deaktiviert und später wieder aktiviert werden, da er einige bereits deaktivierte NotfallZusatzLinks bevorratet, deren Zustand danach wieder restauriert werden müßte.

Sollte eigentlich kein Problem sein. Folgende Möglichkeiten hast du:
- Alle aktivierten Links in einem solchen Paket händisch auswählen und dann deaktivieren
- und/oder: Spalte "Aktiviert/Deaktiviert" anzeigen lassen, Items im Paket entsprechend sortieren und dann alle aktivierten Links deaktivieren
- und/oder: ein EventScripter Script zur Hilfe nehmen, das dabei hilft und gewisse "aktivierte fertige" Items niemals deaktiviert

Originally Posted by sj_rolak

Sehr neugierig wäre ich übrigens auf ein Beispiel, das die aktuelle Haltemarken-Logik zwingend benötigt

Da kann ich dir keines liefern, da ich die Haltemarke selbst noch nie genutzt habe.
Ich kann nur versuchen, mich in die User hineinzuversetzen.
Mein aktueller Stand wäre folgender:
- Das derzeitige Haltemarkenverhalten finde ich okay
- Andere Haltemarken-Modi einbauen fände ich auch okay, besonders die "Lade nichts unterhalb der Haltemarke" Idee
- Wir sind offen für weitere Vorschläge

Originally Posted by sj_rolak

...das länglich von Dir vorgetragene RG/1F-Beispiel zum Normalverhalten der Haltemarke ist jedenfalls keines.

Sollte es auch nicht sein es sollte lediglich das aktuelle Verhalten zeigen unabhängig davon, wie sinnvoll dieses ist.

Originally Posted by sj_rolak

Außerdem werden auch in dieser Situation Pakete angepackt werden, die den 10 Links folgen, solange nicht alle RG-Dateien angekommen sind.

Korrekt.

Zusammenfassung:
Du hättest gerne, dass bei gesetzter Stoppmarke nur Dateien geladen werden, die sich in der aktuellen Liste über der Stoppmarke befinden.

[sj_rolak]

Originally Posted by pspzockerscene

{übers AccountLimit hinaus laden} Das sollte JD sowieso nicht.

Ui, wann hat sich denn das geändert? 2020 mit turbobit als Premium ging das (leider) noch äußerst gradlinig ins Off, wenn nicht aufs Genaueste abgezählt worden war.


btw: über die JDL-Versionen hinweg scheints kein history-log zu geben mit der Liste der implementierten Änderungen/Neuerungen; die Hilfe scheint mir in irgendeiner älteren UI-Variante steckengeblieben und generell ein wenig rudimentär zu sein. Bei solch ödem Kram könnte ich evtl ein wenig Zeit investieren und Texte basteln oder so - falls gewünscht.

{bis zu einer gewissen Uhrzeit} Zeitplaner->Installieren

-done- werd ich mich mal ein wenig reinfuxen müssen

##under development## feel free 2 test // pls feedback##

aha, ich nicht als einzige Person

{?GiB frei lassen} Macht JD bereits

ok - die anscheinend per default eingestellten 128MiB, verhindert deren Unterschreitung einen weiteren DL oder wird vorher geprüft, obs mit dem nächsten DL auch ja nicht daran knabbert? Vor ~5 Jahren hab ich mich nämlich nach Arbeitsunfall und nicht allzu heftiger OP nachts aus dem KH rausgeschlichen, Taxi für kurzen Heimbesuch inklusive Klamotten holen - und daheim war die Kacke am dampfen, JDL blinkte und rackerte unermüdlich und versuchte vergeblich immer weiter, ausstehende DLs dann doch noch runterzuladen. Zugegeben, man sollte nicht darauf setzen, daß man eh mit normalem Arbeitsende lässig rechtzeitig zuhause ist.

{deaktiviert/aktiviert} händisch auswählen

Ja, das war auch hier die bisherige, ungeliebte Variante. In der Form divide et impera, also aus einem Paket zwei machen.

{Beispiel} kann ich dir keines liefern

Heißa, in meinem jugendlichen Leichtsinn ging ich blauäugig davon aus, daß da nicht nur eine mir bisher entgangene Genialität hinter steckt, sondern daß auch irgendwer irgendwann einen wohlformulierten Antrag unterbreitet hat, in dem dann später nachzusehen ist, was warum und wie implementiert worden ist respektive zu funktionieren hat. Das Prinzip 'Pflichtenheft' scheint sich leider kaum irgendwo durchgesetzt zu haben außer dort, wo der dazu notwendige Aufwand jedweden angemessenen Rahmen sprengt..

(Die) Zusammenfassung

trifft es genau - allerdings 'ich hätte gerne' nur im Sinne von 'wäre mir lieber und würde mich freuen', keinesfalls jedoch im Sinne 'und jetzt macht hinne!'

[pspzockerscene]

Originally Posted by sj_rolak

Ui, wann hat sich denn das geändert?

Das war schn immer so.

Originally Posted by sj_rolak

2020 mit turbobit als Premium ging das (leider) noch äußerst gradlinig ins Off, wenn nicht aufs Genaueste abgezählt worden war.

Evtl. gab es irgendwann mal Änderungen an der Turbobit Webseite, weswegen die Downloadlimits beim Accountcheck nicht gefunden wurden?
Werden sie denn derzeit korrekt in JD angezeigt?
Genauso wie bei den Dateigrößen auf die ich weiter unten eingehe gibt es auch Anbieter, die ihre Accountlimits nirgends anzeigen bis man das Limit dann wirklich erreicht...

Wie meinst du eigentlich "übers Accountlimit laden"?
Wenn JD z.B. weiß, dass ein Account nur noch 1GB Traffic hat, wird er erst gar nicht versuchen, 2GB große Downloads mit diesem Account herunterzuladen.
Sobald das Limit erreicht ist wird entweder gewartet bis wieder Traffic da ist oder als Free-User weiter geladen.
Dieses "was passiert, wenn Account Download nicht mehr möglich ist" Verhalten lässt sich wie gewünscht einstellen.
Standardmäßig wird versucht ohne Account zu laden, wenn im Premiumdownload was schiefgeht bzw. ein Accountlimit erreicht wird.

Originally Posted by sj_rolak

btw: über die JDL-Versionen hinweg scheints kein history-log zu geben mit der Liste der implementierten Änderungen/Neuerungen

Korrekt einen Changelog gibt es nicht.

Originally Posted by sj_rolak

Bei solch ödem Kram könnte ich evtl ein wenig Zeit investieren und Texte basteln oder so - falls gewünscht.

Ein Changelog ist nicht geplant.
Wir haben die Frage nach einem Changelog in folgendem Thread genauer beantwortet:
https://board.jdownloader.org/showthread.php?t=87829
Wir dort beschrieben, kannst du unsere Änderungen in Textform in unseren Committ-Messages der Codeänderungen durchlesen.

Originally Posted by sj_rolak

aha, ich nicht als einzige Person

Wie meinst du das?

Originally Posted by sj_rolak

ok - die anscheinend per default eingestellten 128MiB, verhindert deren Unterschreitung einen weiteren DL oder wird vorher geprüft

Prinzipiell wird das vor dem Download geprüft ja, aber du musst bedenken, dass es technisch nicht immer möglich ist, eine (genaue) Dateigröße vor dem Downloadstart zu kennen, weil:
- Manchmal ist einfach keine Dateigröße vom Anbieter gegeben
- Bei HLS Stream Downloads lässt sich die Dateigröße vorher nur grob schätzen
- Manchmal kann auch während des Downloads keine Gesamtgröße bekannt sein. Es wird dann einfach geladen bis fertig.
Wie genau die Logik des "Free Space Checks" funktioniert, kann dir Jiaz ggf. genauer erklären.

Originally Posted by sj_rolak

Das Prinzip 'Pflichtenheft' scheint sich leider kaum irgendwo durchgesetzt zu haben außer dort, wo der dazu notwendige Aufwand jedweden angemessenen Rahmen sprengt..

Ich bin froh, dass wir ohne sowas arbeiten ansonsten wäre die JD Entwicklung um einiges langsamer gewesen

Originally Posted by sj_rolak

trifft es genau - allerdings 'ich hätte gerne' nur im Sinne von 'wäre mir lieber und würde mich freuen', keinesfalls jedoch im Sinne 'und jetzt macht hinne!'

Alles gut ich freue mich ja schon, dass wir nicht aneinander vorbeigeredet haben und ich dein Anliegen richtig verstanden habe.
Wie du anhand des anderen Threads siehst, bist du auch nicht der einzige mit diesem Anliegen.
Wir werden uns das anschauen und uns dann in diesem Thread melden.

[sj_rolak]

Originally Posted by pspzockerscene

Werden sie denn derzeit korrekt in JD angezeigt?

turbobit ist mangels Angebotsdichte letztes Jahr nicht verlängert, sondern gegen 1fichier 'getauscht' worden. Davor wurden sie allerdings korrekt angezeigt.
Falls generell Gegenwart: bei allen hier auftretenden Dateigrößen/hostern stimmts zur Zeit, kenne ich eigentlich auch gar nicht anders.

¿"übers Accountlimit laden"?

Haltemarke einen oder mehr zu tief gesetzt bzw ein Serverhänger weiter oben fürs Durchlaufen und der account wurde auf free gedrosselt, iirc bei ≥40GiB/Tag. Danach trudelte dann noch ne EMail ein, daß für so-und-so-lange nichts mehr ist mit Premium.

Changelog in folgendem Thread genauer beantwortet

OK, es reicht, jetzt wird ein ordentlicher Lesezeichen-Unterbaum für dieses Forum angelegt...

{nicht als einzige Person} Wie meinst du das?

Na, wenn bei Einstellungen/Zeitplaner schon vorab zum fröhlichen Ausprobieren geladen und um Rückmeldung gebeten wird, bin ich ja wohl nicht der einzige Mensch, der sich ins Thema einarbeiten muß, bevor die Zeitplanung sinnvoll eingesetzt werden kann.

technisch nicht immer möglich .. Dateigröße vor dem Downloadstart zu kennen

Nu, damals warens lauter bekannte Dateigrößen - ist aber schon wg 'zu lange her' kaum reproduzierbar. Und noch ein Scheibchen vom Daumen säg ich mir deswegen bestimmt nicht ab...


Übrigens scheint die Entwicklung heute besonders intensiv zu verlaufen, bummelig ne Handvoll updates. Ach ja, vor einigen Tagen wurde auch die seit längerem laufende rot-grün-Lightshow beim click´n´load wieder abgesetzt. Zeigt jetzt bei werdendem Erfolg keinen sekunden(gefühlt Minuten )langen roten Mißerfolgs-screen mehr an. Sehr angenehm für die Augen, thx an wen auch immer.

[pspzockerscene]

Originally Posted by sj_rolak

Haltemarke einen oder mehr zu tief gesetzt bzw ein Serverhänger weiter oben fürs Durchlaufen und der account wurde auf free gedrosselt, iirc bei ≥40GiB/Tag. Danach trudelte dann noch ne EMail ein, daß für so-und-so-lange nichts mehr ist mit Premium.

Verstehe ich nicht ganz.
Die Email dürfte eine normale Benachrichtigung sein und keine "Strafe fürs ausreizen des Limits".
Prinzipiell sollte es doch gar kein Problem sein das Limit zu erreichen.
JD würde dann halt im Free Modus weiterladen. Ist dies dein Problem an dieser Stelle?
Wenn du das nicht möchtest, kannst du entsprechende Account Verwendungsregeln setzen, sodass JD z.B. nicht ohne Account laden darf.
Link:
https://support.jdownloader.org/Know...-free-download

Ich verstehe den Zusammenhang zwischen Account-Limits und Stoppmarke hier nicht.

Originally Posted by sj_rolak

Na, wenn bei Einstellungen/Zeitplaner schon vorab zum fröhlichen Ausprobieren geladen und um Rückmeldung gebeten wird, bin ich ja wohl nicht der einzige Mensch, der sich ins Thema einarbeiten muß, bevor die Zeitplanung sinnvoll eingesetzt werden kann.

Nein das hat eigentlich nichts damit zu tun.
Der rote Text ist lediglich ein Relikt aus 2014 als der Zeitplaner neu war und wir unsere User um Feedback gebeten hatten.
Die Verwendung des Zeitplaners sollte soweit selbsterklärend sein und es sind auch keine Bugs bekannt.
Der besagte rote Text wird mit dem nächsten CORE-update entfernt...

Originally Posted by sj_rolak

Ach ja, vor einigen Tagen wurde auch die seit längerem laufende rot-grün-Lightshow beim click´n´load wieder abgesetzt.

An CNL haben wir nichts geändert. Danke trotzdem für dein Feedback.
Es gab in letzter Zeit immer mal wieder CNL Probleme durch Filecrypt und/oder Änderungen an Browsern (insbesondere Firefox) oder andere Browser Addons z.B. siehe folgender Thread:
https://board.jdownloader.org/showthread.php?t=91838

Jiaz wird beizeit nochmals hier antworten und auf dein gewünschtes "Stoppmarkenhandling" eingehen.

Grüße, psp

[sj_rolak]

Originally Posted by pspzockerscene

Verstehe ich nicht ganz.

TB hatte damals ein DL-Limit von (ich bleib mal bei der erinnerten Menge) 40GiB je Tag. Wurde unbedacht ein insgesamt größerer DL durchgeführt, gabs den erwähnten Ärger.

Die Email dürfte eine normale Benachrichtigung sein

Extrem wahrscheinlich nicht, weil da drin zu lesen war, daß das Tageslimit überschritten worden sei und deswegen etc pp

CNL Probleme

Oha, die Ärmsten - dagegen ists bei mir ja völlig harmlos (gewesen).

[pspzockerscene]

Originally Posted by sj_rolak

Wurde unbedacht ein insgesamt größerer DL durchgeführt, gabs den erwähnten Ärger.
...
Extrem wahrscheinlich nicht, weil da drin zu lesen war, daß das Tageslimit überschritten worden sei und deswegen etc pp

Ich bezweifle ja nicht, dass TB diese Mail verschickte, aber ich vestehe noch immer nicht das Problem:
- Die Mail, die dann kam hat dich einfach gestört?
- TB hat in der Mail sowas geschrieben wie "wenn du das Limit zu oft überschreitest gibt's ne Sperre" o.ä. und daher hattest du mindestens einen Grund, zu vermeiden, das Limit zu erreichen?
- Du würdest einfach gerne eine Möglichkeit haben, JD zu sagen "lade max X GB", sodass du bei gewissen Accounts nie ans Limit stößt?

Letzteres ist nicht möglich.
Falls du aus irgendwelchen Gründen max X GB pro Zeit oder pro Account und Zeit laden möchtest, bleiben dir die folgenden Optionen:
- EventScripter Script dafür basteln
oder:
- Vorher entsprechend so viele Links deaktivieren, dass JD dein gewünschtes Kontingent nicht überschreiten kann

[sj_rolak]

Originally Posted by pspzockerscene

- Mail.. hat dich einfach gestört?
- mindestens einen Grund, zu vermeiden?
- max X GB [==traffic-Limit]
Letzteres ist nicht möglich.

Grüezi, mal ganz abgesehen davon, daß dies für mich (siehe threadDatum) ein lange obsoletes Problemchen ist, da der aktuelle premium 1fichier kein trafficLimit pro Zeiteinheit zu haben scheint: wie verträgt sich letzteres denn mit dem weiter oben gesagten

Originally Posted by pspzockerscene

Wenn JD z.B. weiß, dass ein Account nur noch 1GB Traffic hat, wird er erst gar nicht versuchen, 2GB große Downloads mit diesem Account herunterzuladen.
Sobald das Limit erreicht ist wird entweder gewartet bis wieder Traffic da ist oder als Free-User weiter geladen.

TB mailte übrigens, daß nach den (mir zumindest in diesem und anderen relevanten Punkten bekannten) AGB wegen Limit-Überschreitung der premiumZugriff soundsolange nicht mehr möglich sein wird, was ich durchaus als mehr als 'störend' empfunden habe.
Und selbstverständlich versuche ich, mich an vertraglich vereinbarte Bedingungen zu halten.



**and now for sthg completely different**

Originally Posted by sj_rolak

doch das PasswortSuchen beim Entpacken fiele weg

vermutete ich thread-eingangs, allerdings wird auch bei einem einzigen in der Liste (das vorab einkopierte und nach dem ersten erfolgreich ausgepackten Teilpaket eingelistete) beim Herangehen an jedes neue Teilpaket ein "Passwort knacken: xx%" angezeigt. Ultrakurz, aber immerhin.
Dazu eine Verständnisfrage: Liegt das evtl daran, daß auch eine pwListe der Länge eins stumpf nach Vorgabe <egal welche Listenlänge> abgearbeitet wird, also erst einmal nachgesehen wird, welches der pws von dem einen in der Liste (hat schon was Absurdes, ne?) denn jetzt beim nächsten Teilpaket zuträfe?

[pspzockerscene]

Originally Posted by sj_rolak

wie verträgt sich letzteres denn mit dem weiter oben gesagten

Wie meinst du das?
Accountlimits mit gesetzter Stoppmarke?

Originally Posted by sj_rolak

TB mailte übrigens, daß nach den (mir zumindest in diesem und anderen relevanten Punkten bekannten) AGB wegen Limit-Überschreitung der premiumZugriff soundsolange nicht mehr möglich sein wird, was ich durchaus als mehr als 'störend' empfunden habe.

Danke das beabtwortet meine Fragen und ist ein guter Grund zu versuchen, besagtes Limit nicht mehr zu erreichen. Gleichzeitig ist es aber auch kein JDownloader Problem/Bug.

Originally Posted by sj_rolak

Und selbstverständlich versuche ich, mich an vertraglich vereinbarte Bedingungen zu halten.

Naja man muss auch dazu sagen, dass dies einfach schlecht von turbobit umgesetzt wurde.
Stell dir mal vor, du bekommst in Mcdonalds einen Becher für 1€ und darfst "so viel trinken wie du willst", aber dann wird dir nach dem dritten Becher Ladenverbot angedroht: Die Limits sollte man von vorneherein klar angeben und serverseitige Limits einrichten dann muss man auch keine Kunden ermahnen.

Originally Posted by sj_rolak

Dazu eine Verständnisfrage: Liegt das evtl daran, daß auch eine pwListe der Länge eins stumpf nach Vorgabe <egal welche Listenlänge> abgearbeitet wird, also erst einmal nachgesehen wird, welches der pws von dem einen in der Liste (hat schon was Absurdes, ne?) denn jetzt beim nächsten Teilpaket zuträfe?

Verstehe ich nicht ganz.
Der Ablauf ist wie folgt:
- Falls du dem Archiv in JD ein Passwort vorgibst, wird dieses zuerst versucht.
- Ist das Passwort nicht korrekt, wird die Passwortliste von oben bis unten abgearbeitet.
- Wird am Ende kein passendes PÜ gefunden, wird je nach Einstellung der User gefragt oder aufgegeben.

Grüße, psp

[sj_rolak]

Originally Posted by pspzockerscene

Wie meinst du das?

In #28 schriebst Du 'nein, das geht nicht'

eine Möglichkeit .., JD zu sagen "lade max X GB", sodass du bei gewissen Accounts nie ans Limit stößt?

.. ist nicht möglich.

jedoch in #24 'ja, das ist StandardVerhalten'

Wenn JD z.B. weiß, dass ein Account nur noch 1GB Traffic hat, wird er erst gar nicht versuchen, 2GB große Downloads mit diesem Account herunterzuladen.
Sobald das Limit erreicht ist wird entweder gewartet bis wieder Traffic da ist oder als Free-User weiter geladen.

einen Becher für 1€ und darfst "so viel trinken wie du willst", aber dann wird dir nach dem dritten Becher Ladenverbot angedroht

Wie kommst Du auf die Idee? TB gab von Anfang an ein TrafficLimit von iirc 40GiB/d vor und JD hielt sich (ua nach 'Durchbrechen' der Haltemarke wg eines parts mit ServerProblem/Wartezeit) keineswegs an Dein 'warten oder free'.

ein guter Grund zu versuchen, besagtes Limit nicht mehr zu erreichen

Ein Scherz, ne? Das ist genau eines der Kernthemen bei Erstellung dieses threads gewesen.

kein JDownloader Problem/Bug

O RLY? Obgleich er nicht leistet, was er vorgeblich leistet?

Verstehe ich nicht ganz. Der Ablauf ist wie folgt:

Noch'n Scherz? Das danach Folgende ist exakt die Wiederholung des von mir Gefragten. Selbstverständlich ist mir nicht zu jeder Programmiersprache alles klar nach bescheidenen 50y SoftwareEntwicklung, doch statt des anscheinend implementierten

if (givenPW) and decryptTest(givenPW)=success
 then takenPW:=givenPW
 else foreach(PWlist) do {takenPW:=PWlist(); if decryptTest(takenPW)=success then break};
try decrypt(takenPW) fail ('PW passt nicht')

halte ich

if (givenPW)
 then {try decrypt(takenPW) fail ('PW passt nicht')}
 else {foreach(PWlist) do {takenPW:=PWlist(); if decryptTest(takenPW)=success then break};
       try decrypt(complete, takenPW) fail ('PW passt nicht')
       }

für eine deutlich angemessenere Umsetzung eines 'Archive/ArchivPasswort setzen' (im Gegensatz zum implementierten 'Archive/wahrscheinliches ArchivPasswort zusätzlich angeben') - auch wenn, wie bereits von Anfang an gesagt, es laufzeitlich kaum relevant ist.
~#~#~

Originally Posted by pspzockerscene

{Rest auf Laufwerk freilassen}
Macht JD bereits.
Den Wert kannst du beliebig ändern siehe ..

Der Punkt ist, daß JD in diesem Falle sämtliche noch unerledigten DLs startet, um dann festzustellen, daß es doch nicht geht - und zwar auch völlig unbekümmert von Haltemarken (im Beispiel bei 'The Collection' und ja, alle DL-Größen vorab bekannt):

[pspzockerscene]

Originally Posted by sj_rolak

In #28 schriebst Du 'nein, das geht nicht'

Nein.
Nochmal:
Ich habe deine Frage so verstanden, dass wissen wolltest, ob man in JDownloader manuell Limits auf Accounts setzen kann z.B. "Lade max 10GB pro Tag von turbobit.net über Account XY" --> Das ist nicht möglich!

Originally Posted by sj_rolak

jedoch in #24 'ja, das ist StandardVerhalten'

Das Standardverhalten ist, dass JD sofern ein Account-Limit bekannt ist, sich an dieses hält.

Originally Posted by sj_rolak

Wie kommst Du auf die Idee? TB gab von Anfang an ein TrafficLimit von iirc 40GiB/d vor und JD hielt sich (ua nach 'Durchbrechen' der Haltemarke wg eines parts mit ServerProblem/Wartezeit) keineswegs an Dein 'warten oder free'.

Meine Annahme ergab sich aus deiner Frage, die ich scheinbar falsch verstanden habe.
Wie gesagt: Sofern in JDownloader im Accountmanager Limits zu sehen sind, hält sich JD an diese.
Ist dies nicht der Fall, hast du ggf. einen Bug gefunden dann bräuchte ich eine genaue Fehlerbeschreibung und einen Log.
JDownloader prüft Accounts standardmäßig alle 30 Minuten also falls man z.B. parallel etwas per Browser über denselben Account herunterlädt kann es schonmal passieren, dass JD "versucht" ein Limit zu überschreiten.
Dies sollte aber kein Problem darstellen, da die Plugins dies idR. erkennen und einen entsprechenden Fehler anzeigen bzw. Accounts mit "Limit erreicht" Fehlermeldungen entsprechend temporär deaktivieren (gelber Account-Fehlerstatus).

Originally Posted by sj_rolak

Ein Scherz, ne? Das ist genau eines der Kernthemen bei Erstellung dieses threads gewesen.

Ich kann dir versichern, dass ich deine Posts nicht absichtlich falsch interpretiere.
Derzeit sehe ich uns in diesem Thread aber nicht vorankommen...

Originally Posted by sj_rolak

für eine deutlich angemessenere Umsetzung eines 'Archive/ArchivPasswort setzen' (im Gegensatz zum implementierten 'Archive/wahrscheinliches ArchivPasswort zusätzlich angeben') - auch wenn, wie bereits von Anfang an gesagt, es laufzeitlich kaum relevant ist.

Ich verstehe das Problem nicht was passt denn am bisherigen Archiv-Passwort-Handling nicht?
Konkrete Codeänderungen darfst du gerne auch selbst umsetzen, einfach per support@jdownloader.org Schreibrechte anfordern.

Originally Posted by sj_rolak

Der Punkt ist, daß JD in diesem Falle sämtliche noch unerledigten DLs startet, um dann festzustellen, daß es doch nicht geht - und zwar auch völlig unbekümmert von Haltemarken (im Beispiel bei 'The Collection' und ja, alle DL-Größen vorab bekannt)

Nein das kann ich nicht bestätigen.
Wenn nicht genug Speicherplatz verfügbar ist und JD die Dateigrößen der zu ladenden Dateien bereits kennt, wird er diese ohne Versuch direkt überspringen und den Status aus deinem Screenshot direkt auf alle betroffenen Files setzen.
Solltest du an dieser Stelle einen Bug vermuten bitte ich dich darum, eine genaue Fehlerbeschreibung und einen Log zur Verfügung zu stellen, siehe:

Please post your log-ID here | bitte poste deine Log-ID hier.

-psp-
EDIT

Also sollten weiterhin Unklarheiten herrschen, sollten wir uns ggf. einfach zu einer Teamviewer Sitzung verabreden oder per Discord ein Gespräch starten ansonsten werden wir uns ggf. beide die Finger in diesem Thread wundschreiben und zu keinem Ergebnis kommen.