[oEFLKQzikCqw]

Aha, das bezieht sich auf den Status innerhalb des JD und nicht auf die Zwischenablage.

Leider ist gestern das Problem wieder einmal aufgetreten. Es scheint aber so, als ob das jetzt seltener auftritt. Leider lässt sich das hier nicht reproduzieren bzw. ich habe den Weg dafür noch nicht gefunden.

[Jiaz]

Falls Gewünscht kann ich gerne mal einen Debug Modus einbauen der jeden Wechsel *dokumentiert*. An der Wechselerkennung gab es seit langem keine Änderung. Lediglich an den Optionen für den *ersten Übergang* wie in diesem Thread beschrieben

[oEFLKQzikCqw]

Ja das wäre wohl sinnvoll.

[Jiaz]

Reicht es dir wenn die Infos auf der Console stehen oder willst das in nem File?

[oEFLKQzikCqw]

Ich würde File vorziehen. Es würde nerven, JD immer aus der Konsole starten zu müssen, bis man brauchbare Infos erhält, schließlich weiß ich ja nicht wann das unter welchen Umständen auftritt.

[Jiaz]

Oki, bau ich die Woche ein, geb dir dann hier Bescheid wie der Advanced Settings Key heisst.

[oEFLKQzikCqw]

Geht klar.

[oEFLKQzikCqw]

Mittlerweile habe ich den Verdacht, dass der Link nicht mehr wirklich unterschlagen wird, sondern es nur ewig dauert, bis der Bollontipp kommt und der Link im Linksammler landet. Zumindest hatte ich seit dem Letzten Mal nur starke Verzögerungen beim ersten Link beobachten können, wobei der Bollontipp dann plötzlich sofort mit dem des zweiten Link kam. Er kommt allerdings auch alleine, wenn man länger wartet.

[Jiaz]

Einstellungen-Profieinstellungen-BubbleNotify.bubblenotifyonnewlinkgrabberlinkson
ALWAYS->Balloon kommt sofort wenn mit dem Verarbeiten angefangen wird
PLUGIN -> Balloon kommt sobald das erste Plugin loslegt
LINK -> Balloon kommt sobald es einen ersten gefunden und verarbeiteten Link gibt

[oEFLKQzikCqw]

Hmm, steht bei mir überall auf Link. Das könnte in einigen Fällen die Verzögerung erklären. Aber leider nicht in allen. Ich hatte die Verzögerung auch wenn erster und folgende Links vom gleichen Typ sind, z. B. HTTP-Links, die JD direkt aus der Zwischenablage verwursten kann ohne deren Inhalt laden und analysieren zu müssen. Auch schaffe ich es bei solchen Links in der Regel nicht, den nächsten Link in die Zwischenablage zu kopieren bevor JD den Ballontipp für den letzten Link zeigt. Deshalb fällt da die Verzögerung bzw. Unterschlagung beim ersten Link ja überhaupt erst auf.

Bisher ist das aber lediglich ein Verdacht, der sich schlecht überprüfen lässt, wenn das Problem so selten auftritt und sich nicht reproduzieren lässt.

[Jiaz]

Links können NIE direkt ausm Clipboard verwurstet werden Alles durchläuft erst den Linkcrawler und was dort als Link raus kommt, das zählt.

[oEFLKQzikCqw]

Ich meinte solche Links, die hinten genauso wieder herauskommen, wie man sie vorne eingeworfen hat.

Nennenswerte Verzögerungen sind seit meinem letzten Beitrag hier im Thread nicht mehr aufgetreten. Dafür hat der JD mir gestern Nacht wieder einmal den ersten Link unterschlagen. Es gab zuvor noch einen weiteren Fall, bei dem ich mir aber nicht sicher war, ob das nicht vielleicht doch mein Fehler war.

07.11.16 00.58.21 <--> 07.11.16 01.47.14 jdlog://4696881887641/

[Jiaz]

Selbst Links bei denen Rein=Raus gilt durchwandern erst den Linkcrawler. Je nachdem ob der PluginCache grad *hot* ist, weitere Linkcrawler laufen...geht das eben auch schneller oder langsamer.

Laut Log gabe es alle 4-5 Sekunden eine Änderungen im Clipboard? Hast du da Links einzeln hinzugefügt?

[oEFLKQzikCqw]

Ja hab ich und ich schrieb doch auch schon mehrfach, dass das nur bei einzeln hinzugefügten Links passiert.

War da irgend ein Link doppelt im Log? Eigentlich hätten der erste und der vierte identisch sein müssen.

[Jiaz]

Ich sehe keine Links, nur das ein *Wechsel* statt gefunden hat.

[oEFLKQzikCqw]

Dann war das Log leider wenig hilfreich. Würde Debug Mode aktivieren helfen? Wie viele Wechsel gab es denn?

[Jiaz]

Du kannst JDownloader im Terminal starten, dann kannst auf der Console jeden Wechsel sehen.

[oEFLKQzikCqw]

Ich sehe da dann so etwas:

Show
IDLE TIME CALL DURATIOn: 1
Highlight
Flash: false
Enter
Exit
Show
IDLE TIME CALL DURATIOn: 0
Highlight
Flash: false
Show
IDLE TIME CALL DURATIOn: 0
Highlight
Flash: false
Show
IDLE TIME CALL DURATIOn: 0
Highlight
Flash: false
Show
IDLE TIME CALL DURATIOn: 0
Highlight
Flash: false
Show
IDLE TIME CALL DURATIOn: 0
Highlight
Flash: false

Das war jetzt aber ohne das Problem, welches inzwischen nur noch sehr selten auftaucht.

[Jiaz]

Halte Ausschau nach sowas:
LinkCollector(addCrawlerJob)] -> Added CrawlerJob jd.controlling.linkcollector.LinkCollectingJob

Die einzig nachvollziehbare Möglichkeit das es zu *Verlusten* kommt ist das du schneller was in die Zwischenablage legst, als das die Applikation das auslesen ermöglicht. JDownloader pollt alle 100ms (10x pro Sekunde) das Clipboard. Du kopierst jetzt was ins Clipboard. 100ms später merkt JD den Wechsel und will auslesen und in dem Moment kopierst du was neues ins Clipboard-> Es kann folgendes passieren:
-Alles normal, JD liest Clipboard aus
-Beim Auslesen des Clipboard knallt es weil Lesen<->Schreiben nicht so gut kommt->Clipboard verloren
-Das Auslesen dauert länger (weil zb die Application nur langsam die Daten hergibt) ->Wechsel wird bemerkt aber kann nicht rechtzeitig ausgelesen werden.
All diese Fälle können nicht behandelt/gelöst werden

[oEFLKQzikCqw]

Das, was ich vorhin als Code postete, war alles, was in der Konsole nach dem Kopieren der Links in die Zwischenablage in der Konsole auftauchte. Die Links landeten im Linksammler und es gab sie schon in der Downloadliste.

Ich schaffe den nächsten Link mit Sicherheit nicht innerhalb von 100ms in die Zwischenablage zu kopieren. Viel schneller als die schon von dir aus dem Log entnommenen alle 4-5 Sekunden wird das nicht.