NEWS
UNSOLVED Javascript - Blockly wird oft nicht gespeichert
-
@apollon77 was auch immer mal passiert ist der anstieg des speicherverbrauches des object tabs
normal um die 500 aber wenn das system "ziggt" werden es 2000 und die cpu geht auch hoch- nach tab refresh wird es wieder weniger
hier im beispiel gerade geöffnet
-
"Wer" ist denn für das speichern generell verantwortlich? Es ist ja nicht nur JS/Blockly. Ich hatte eben wieder den Fall in meiner noch Recht bescheidenen View, dass ich nur ein Widget "Basic Number" hinzufügen wollte. Nach der Auswahl des DPs wollte er wegen der Änderung wieder speichern, was unüblich lange dauerte. Danach war zwar noch das Widget in den Eigenschaften unter W...xyz ausgewählt, aber gänzlich ohne Inhalt und in der Preview war das Widget kpl. weg. Das trat beim frisch gestarteten System/Browser auf. Danach habe ich nur die Seite refresht (also mal kein Cache etc. geleert) und es noch einmal probiert. Funktionierte anstandslos.
Mir sieht das fast so aus, dass man ein Problem bekommt wenn man genau im "falschen" Augenblick speichert... -
@SBorg den eindruck des falschen augenblicks beim speicher kann ich bestätigen
-
Habt ihr auch das blockly nach dem speichern in die erste Zeile springt, aber trotzdem gespeichert wurde?
Das kommt seit neustens ab und zu bei mir vor...
-
ob es die erste zeile ist, weiß ich nicht - aber blockly springt bei mir auch
-
Und ist dann bei dir immer nicht gespeichert?
-
@saeft_2003 nein - interessanterweise : wenn es springt kann ich speichern -das springen hat ausser "nerven", weil man wieder zur alten stelle im script zurück muss, keine auswirkung
-
Ich habe das springen gelegentlich nur direkt nach dem speichern. Zu 80% wurde nicht gespeichert und zu 20% wurde trotz dem springen gespeichert...
-
@saeft_2003 stimmt - das springen kommt eigentlich immer nach dem speichern - ob dann nicht gespeichert wird, kann ich dir garnicht sagen - ist mir noch nicht aufgefallen
-
@liv-in-sky sagte in Javascript - Blockly wird oft nicht gespeichert:
ich arbeite immer mit mehreren offenen admin tabs
Das mach ich absichtlich nie. (aus Angewohnheit, da es mit einem online Programm, was ich für die Arbeit täglich nutze auch nicht funktioniert)
Wenn ich das mit besagten Programm von meiner Arbeit vergleiche....dort wird mit Sessions gearbeitet, das heißt, ich müsste mich in zwei Fenstern (nicht nur Tabs) separat anmelden, dann funktioniert es. Wenn ich da Tabs nehme und in einem arbeite und dann im zweiten was tun möchte, dann nimmt nach dem nächsten Klick im zweiten Tab dieser den Zustand des anderen an.
Wie sich an dieser Ecke ioBroker verhält weiß ich nicht. -
@dslraser kann ich absolut nachvollziehen
hatte aber vorher nie probleme damit - da das script tab immer lange braucht, bis es öffnet, wäre ein flüssiges arbeiten gar nicht möglich - ich brauche oft den object-tab und den log tab(hab ich mittlerweile in anderen browser) dazu um zu programmieren
wenn ich nur noch mit einem tab arbeiten dürfte, wäre das eine echt immense verschlechterung für mich
aber ich glaube, es wurden schon viele browser getestet und da wird wohl meist nur ein tab auf sein - vermute ich - und die probleme waren auch da
-
@liv-in-sky Ja, keiner hat gesagt das in Redis ein Objekt nur einen Key hat Files haben zwei - und werden in Admin nicht angezeigt ... Was mehr ist sind also eher deine Files
-
So, wir haben mal ein bissl an den socket.io ping/pong timeouts rumgespielt ... Dazu checkt bitte mal Admin 4.1.6 ... Also: Admin installieren, Javascript am besten so lassen wie es probleme machte. Dann Auf jeden Fall mal im browser reloaden (hart) ode rbrwoser zu und auf und so ... ... Besser?
Die 4.1.6 NICHT auf GitHub installieren, das geht nicht so simpel ... also kurz warten bis es im Latest Repo auftaucht bitte!
-
@apollon77 alles ok - wollt nur mal wissen, ob das sein kann - war aber früher auch schon so - also kein thema
admin teste ich, wenn angezeigt wird
-
@liv-in-sky Bei Sigi schon da,, also mal reloaden
-
@apollon77 läuft schon
-
Vorsichtig optimistisch. Wird sich erst noch die Tage zeigen ob die Fehler tatsächlich weg sind. Aber Ingo egal was du/ihr gedreht habt, es läuft bei mir nun wesentlich performanter
-
@SBorg den eindruck kann ich bestätigen - werde aber noch weiter prüfen - heute morgen (und seit gestern) noch kein problem mit javascript
blockly noch nicht getestet
-
@SBorg sagte in Javascript - Blockly wird oft nicht gespeichert:
egal was du/ihr gedreht habt
Am Ende haben wir das "socket.io Ping Pong" (was ja meine vermutung war das das irgendwie probleme macht wenn das Javascript mal länger beschäftigt ist (zB durch umwandeln eines grossen Blocklies in ein json/XML) ) verlängert. Von bisher alle 25s mit nem 5s Timeout auf jetzt 120s mit 30s Timeout ...
-
ja - das merkt man- sonst war immer beim speichern von javascript in dem augenblick, wo man speicherte, ein zeilensprung im editor (ein oder 2 zeilen)
ich wußte dann, jetzt ist wieder nicht gespeichert worden
und jetzt: kommt auch so ein zeilensprung im editor - aber das script wird gespeichert