|
#1
|
|||
|
|||
[JD2] Linkgrabbersetting verschwunden
Ich hatte JD über die Profieinstellungen so eingestellt, dass er beim Start mit aktivierter Clipboardüberwachung oder bei deren Aktivieren erst dann tätig wird, wenn der Inhalt des Clipboards sich ändert. Heute wurde ich davon überrascht, dass das nicht mehr funktioniert und ich kann die entsprechende Einstellung (Namen leider nicht gemerkt) in den Profieinstellungen auch nicht mehr finden. Abgesehen davon hat der JD hin und wieder den ersten in das Clipboard kopierten Einzellink ignoriert.
Bitte diese Einstellung wiederherstellen. |
#2
|
||||
|
||||
Es gab hier keinerlei Änderungen. GraphicalUserInterfaceSettings.skipclipboardmonitorfirstround
__________________
JD-Dev & Server-Admin |
#3
|
|||
|
|||
Da war ich wohl blind. Allerdings frage ich mich, warum die Einstellung zurückgesetzt wurde, wobei ich nicht völlig ausschließen will, dass ich die in dieser Installation noch gar nicht gesetzt hatte.
|
#4
|
||||
|
||||
Es wurde nichts zurückgesetzt und das ist der Default Wert (also deaktiviert)
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
Tja dann hatte ich diese Einstellung doch noch nicht gesetzt.
Abgesehen davon, die Einstellung funktioniert aktuell nicht richtig, d. h. sie funktioniert nur beim Start, nicht jedoch wenn ich Links in die Zwischenablage kopiere und anschließend die Überwachung einschalte. Das war schon mal anders. Ob weiterhin immer wieder mal der erste Link unterschlagen wird, kann ich noch nicht sagen. |
#6
|
||||
|
||||
Also an der Funktion hat sich nichts geändert, aber ich werde sie etwas umbauen, dass Sie auch während einer Session wie gewünscht funktioniert
__________________
JD-Dev & Server-Admin |
#7
|
|||
|
|||
Danke. Aber warum hat das denn bisher funktioniert?
|
#8
|
||||
|
||||
Fehler lag an einer Logikänderung. Sollte mit nächste Core Update wieder wie gewünscht funktionieren
__________________
JD-Dev & Server-Admin |
#9
|
|||
|
|||
Danke. Hoffentlich ist damit dann auch das Problem, dass hin und wieder der erste Einzellink aus der Zwischenablage unterschlagen wird, beseitigt.
|
#10
|
|||
|
|||
Quote:
|
#11
|
|||
|
|||
Mit dem Update hat sich scheinbar das Default-Verhalten geändert. Für die "Clipboard Skip Mode" ist aktuell (core #34915) "ON_STARTUP" der Default-Wert. Vorher wurden Links beim Starten standardmäßig akzeptiert, ich finde das ist auch das sinnvollere Default-Verhalten.
|
#12
|
||||
|
||||
@jitter:
Hab den Default geändert
__________________
JD-Dev & Server-Admin |
#13
|
||||
|
||||
Wäre Teamviewer möglich? Ich kann das Problem nicht nachvollziehen auf Windows7/Windows8/Linux gehts ohne Probleme. Egal wie, es geht immer.
__________________
JD-Dev & Server-Admin |
#14
|
|||
|
|||
Auch wenn es hier relativ oft auftritt, ist das hier leider nicht mit Sicherheit reproduzierbar. Es tritt zudem immer nur bei einem einzelnen Link auf und nie bei mehreren Links (ein Link pro Zeile). Ob das auch mit einem oder mehreren Links in einem einzeiligem Text auftritt, ist mir nicht bekannt.
Laut dem von mir verlinkten Thread konntest du das ja inzwischen reproduzieren, so dass Teamviewer wohl nicht mehr nötig sein dürfte. |
#15
|
||||
|
||||
Bitte mal updaten. Hab das Problem von dabrown nachvollziehen können. Evtl war es auch das Problem von dir.
__________________
JD-Dev & Server-Admin |
#16
|
|||
|
|||
Bisher ist es noch nicht wieder aufgetreten. Werde das aber noch eine Weile beobachten müssen, bis klar ist, dass das Problem wirklich weg ist.
Edit: Dafür ist jetzt GraphicalUserInterfaceSettings.skipclipboardmonitorfirstround wirklich weg und JD verhält sich beim Aktivieren der Clipboardüberwachung dementsprechend. Wie das Beim Start aussieht werde ich noch testen. Edit2: Beim Start wird der Inhalt des Clipboard nicht übernommen, obwohl GraphicalUserInterfaceSettings.clipboardskipmode auf never steht. Diese Prefs hat offensichtlich die erste verschwundene ersetzt. Edit3: Nachdem ich beim Skipmode die Einstellungen durch bin, verhält sich JD leider wie es zu erwartet ist. Leider deshalb, weil so nur entweder on_startup oder on_enable möglich ist und nicht beides gleichzeitig. Die Checkboxen in der Einstellung sollten daher besser durch Radiobuttons ersetzt werden. Mir ist schon klar, dass ich beides gleichzewitig nicht benötige, wenn ich die Überwachung tatsächlich immer nur bei Bedarf aktiviere. Aber das ist nicht immer der Fall und sei es nur, dass ich das Deaktivieren wieder vergesse. Abhilfe könnte da neben einer zusätzlichen Option in der schon existierenden Prefs alternativ die Möglichkeit sein, dass JD beim Beenden vergisst, dass die Überwachung aktiviert war. Last edited by oEFLKQzikCqw; 21.09.2016 at 20:51. |
#17
|
|||
|
|||
Leider gibts da doch noch ein Problem. Bei on_enable funktioniert das hier nicht bei der ersten Aktivierung nach dem Start, bei allen weiteren allerdings schon.
|
#18
|
||||
|
||||
Hab da noch nen Fehler in der Logik gehabt.
Never-> Niemals die erste Runde überspringen On_Startup-> Nur während dem JDownloader start die erste Runde überspringen On_Enable-> Immer die erste Rune überspringen Eine Runde entspricht einer Änderung des Inhaltes der Zwischenablage.
__________________
JD-Dev & Server-Admin |
#19
|
|||
|
|||
Das ist aber auch nicht wirklich das, was ich für sinnvoll halte. Sinnvoll ist hier lediglich den zum Zeitpunkt der Aktivierung der Überwachung bzw. Start von JD aktuellen Inhalt der Zwischenablage zu ignorieren und nicht auch noch die erste Änderung der Zwischenablage danach. Oder zählt hier das erstmalige Einlesen schon als erste Änderung?
|
#20
|
||||
|
||||
Ähm...das ist das gleiche
Die erste Runde ist Nix zum ersten Inhalt. Leer (Runde 0) Leer (Runde 0) Leer (Runde 0) Erste Änderung (Runde 0 verarbeiten, Runde wechselt auf 1) Zweite Änderung (Runde 1 verarbeiten, Runde wechselt auf 2)
__________________
JD-Dev & Server-Admin |
#21
|
|||
|
|||
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. |
#22
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#23
|
|||
|
|||
Ja das wäre wohl sinnvoll.
|
#24
|
||||
|
||||
Reicht es dir wenn die Infos auf der Console stehen oder willst das in nem File?
__________________
JD-Dev & Server-Admin |
#25
|
|||
|
|||
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.
|
#26
|
||||
|
||||
Oki, bau ich die Woche ein, geb dir dann hier Bescheid wie der Advanced Settings Key heisst.
__________________
JD-Dev & Server-Admin |
#27
|
|||
|
|||
Geht klar.
|
#28
|
|||
|
|||
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.
|
#29
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#30
|
|||
|
|||
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. |
#31
|
||||
|
||||
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.
__________________
JD-Dev & Server-Admin |
#32
|
|||
|
|||
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/ |
#33
|
||||
|
||||
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?
__________________
JD-Dev & Server-Admin |
#34
|
|||
|
|||
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. Last edited by oEFLKQzikCqw; 08.11.2016 at 11:57. |
#35
|
||||
|
||||
Ich sehe keine Links, nur das ein *Wechsel* statt gefunden hat.
__________________
JD-Dev & Server-Admin |
#36
|
|||
|
|||
Dann war das Log leider wenig hilfreich. Würde Debug Mode aktivieren helfen? Wie viele Wechsel gab es denn?
|
#37
|
||||
|
||||
Du kannst JDownloader im Terminal starten, dann kannst auf der Console jeden Wechsel sehen.
__________________
JD-Dev & Server-Admin |
#38
|
|||
|
|||
Ich sehe da dann so etwas:
Code:
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 |
#39
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#40
|
|||
|
|||
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. Last edited by oEFLKQzikCqw; 08.11.2016 at 13:28. |
Thread Tools | |
Display Modes | |
|
|