LSS-Manager V.4

Da kann man noch so viel testen und ausgerechnet die einfachsten Testfälle vergisst oder übersieht man ganz gerne ?

Zitat von juli195

Guten Morgen,

Jan (jxn_30), bei mir ist ein kleiner, aber feiner, Fehler aufgetreten. Dieser hat sich schon mehrfach gezeigt:

Wie wir sehen, befindet sich der RTW im Status 5, er hat einen Sprechwunsch. Er wird allerdings in der Linkvorschau mit dem Status 3 angezeigt.

Dies sind alle Funktionen, die ich aktuell aktiv habe:

"Allgemeine Verbesserungen", "Benachrichtigungen", "Chat-Erweiterungen", "Creditszusammenfassung", "Dashboard", "Einsatzhelfer", "Erweiterte Einsatzliste", "Erweitertes Alarmfenster", "Gebäude-Kurzinfos", "Share-Alliance-Post", "Statuszähler" und "Verbesserte Karte"

Dies ist das Skript, welches zusätzlich aktiv ist:

Status aller Fahrzeuge gleichzeitig setzen (zum Thread und Post)

Es hat bei Weitem keine Eile, ich finde Deine / Eure Arbeit mega gut, aber vielleicht findet sich eine Lösung.

Alles anzeigen

Hmm, da scheint die Aktualisierung des Status nicht ganz hinterher zu kommen oder die Änderung ist nicht so verfügbar, dass das im Sprechwunsch-Fenster auch erkannt wird.

Ich schaus mir aber gerne mal an

Zitat von EG112

1. Kann man das Einstellungsfenster in der V4 kleiner machen?

2. Platzierung und Größe des Einstellungsfensters evtl. ähnlich wie bei der V3.

Wie wärs damit?

Wer diesen Bug in Version 4.5.1 reproduziert bekommt, bekommt einen virtuellen Keks von mir geschenkt

So, Spaß beiseite. Sobald die nächste Version draußen ist, werden die Heatmap-Einstellungen kleiner sein und man kann das Fensterchen beliebig verschieben

Zitat von EG112

4. Was mich persönlich allerdings am meisten davon abhält die Heatmap der Version V4 zu verwenden, ist der Umstand das eine Änderung der Einstellungen erst nach einem Klick auf "Speichern" sichtbar wird, und zum 2. eben das riesige Einstellungsfenster.

Jenachdem was meine Konzentration heute macht wird das dann auch mit dem nächsten Update kommen

Eine kurze Information:

In letzter Zeit kommt es leider vermehrt zu Abstürzen des Browser-Tabs in Verbindung mit dem LSSM. Chrome Nutzer sehen dann oft ein "Out of Memory", Firefox zeigt ein "Dieser Tab ist gerade abgestürzt" an.

Wir sind uns dieser Probleme schon länger bewusst und untersuchen die Problematik auch schon länger. Da sich die Probleme nun aber häufen wird sich der Fokus unserer Arbeit nun erstmal auf diese Ermittlungen legen.

Die Probleme treten ziemlich unabhängig von Modulen auf, das heißt die Problematik liegt ziemlich wahrscheinlich (hauptsächlich) im Kern des LSSM.

Wenn sich jemand zufällig mit dem Debuggen von "Out of Memory"-Problemen in Webbrowsern auskennt, gerne melden: Ich hab aktuell gefühlt nurnoch Fragezeichen im Kopf

Tut mir echt leid für die Probleme, die wir verursachen. Sorry ?

Zitat von Ahnungsloser

Ganz ehrlich Jan, eigentlich löst Ihr deutlich mehr Probleme, als dass Ihr welche bereitet. Danke für Eure vielen nützlichen Helfer im LSS-Manager.

Danke für die Blumen

Dank der Mithilfe von okeks versteh ich nun ein bisschen besser, warum der Memory (Arbeitsspeicher) voll läuft und ich versuche das mal so verständlich zu erklären:

Jedes mal, wenn ein Tab oder ein Fenster in einer Lightbox geöffnet wird, wird in diesem eine LSSM-Instanz erzeugt. Das ist zugegeben nicht sonderlich performant, aber sollte in erster Linie kein Problem darstellen und vor allem keine "Out of Memory" Fälle generieren.

Normalerweise ist der Browser und JavaScript so schlau, den Inhalt des Speichers zu löschen, wenn er nichtmehr benötigt wird. Das ist sehr leicht gesagt aber eigentlich ein großes Problem, denn blöderweise ist unentscheidbar, wann ein Objekt als "nicht mehr benötigt" zählt. d.h. der Garbage-Collector (der ist dafür zuständig ein bisschen im Arbeitsspeicher aufzuräumen) von JavaScript versucht so viel wie möglich von dem zu entfernen, was nicht mehr benötigt wird. Leider ist das weder in der Theorie noch in der Praxis vollständig möglich, d.h. man muss damit rechnen, dass immer ein bisschen was übrig bleibt.

Was ist jetzt aber das eigentliche Problem? Jedes mal, wenn ein Fenster entladen wird (man wechselt auf eine andere Seite, schließt die lightbox, etc.) sollte der Arbeitsspeicher, der dafür benutzt wurde, freigegeben werden. Ist der LSSM nun aktiv, so verhindert er dies. Im Arbeitsspeicher sammeln sich also auch LSSM-Instanzen von bereits geschlossenen Fenstern an. Das ist natürlich kacke, weil diese sind ja eh nichtmehr nutzbar (Fenster existiert nichtmehr) und benötigt werden sie auch nicht mehr. Warum werden diese Instanzen vom Garbage-Collector nicht weggeräumt? Ehrlich: Ich weiss es nicht!
Aktuelles Ziel ist es erstmal kurzfristig das so hinzubekommen, dass der Datenmüll weggeräumt wird. Ich hab schon ein paar Kleinigkeiten versucht, aber funktioniert hat das alles blöderweise noch nicht.

Wenn das nicht klappt (auch wenns klappt, aber dann ist es ein langfristigeres Ziel) müssen wir den Core, also den LSSM-Kern, umschreiben. Das wird ziemlich sicher in einem Update des installierten User-Scripts führen. Theoretisch sollte Tampermonkey damit automatisch melden, wenn es soweit ist, aber wir werden trotzdem auf jeden Fall nochmals Hinweise an verschiedenen Stellen geben, damit man ein Update manuell triggern kann. Was für Änderungen hab ich da vor? Relativ einfach (haha, sagt er so leicht…): Der Core wird nurnoch einmal pro Tab geladen. Öffne ich nun eine Lightbox (z.B. einen Einsatz) in diesem Tab, so verwendet dieses Sub-Fenster den selben Core. Das sollte nicht nur die Ladezeiten des LSSM verbessern sondern auch die "Out of Memory" Probleme lösen. Bis es soweit ist braucht es aber sicher noch Zeit und außerdem wurde mir geraten, die anstehende Klausurenphase nicht ganz mit LSSM auszufüllen sondern auch ab und zu einen Blick auf den Stoff für die Prüfungen zu werfen. Wie auch immer: Ich seh das natürlich als spannendes Projekt und eine gute Chance, mein Wissen zu erweitern.

Im Spoiler pack ich für Interessierte (und die es werden wollen) mal noch eine Info, was unser Core eigentlich ist, was er macht und wieso wir den brauchen:

Ich wünsche euch eine schöne restliche Woche, genießt die Tage und freut euch auf ein hoffentlich baldiges Update,

euer Jan

Leude, das ist gleichzeitig zum Lachen und zum Heulen:

Die ganze Geschichte war (ist) unter anderem ein Problem, das durch das User-Script entstanden ist. Da muss man auch erstmal drauf kommen…

Wär hätte gedacht, dass so wenige changes (61d0d06, 2 changed files with 12 additions and 3 deletions) dieses Memory Problem lösen wird?

Wir werden das ganze jetzt nochmals ausgiebig testen, dann hoffen wir, dass ich hier nicht zu viel verspreche, und dann wird es wohl demnächst ein Update des User-Scripts geben

Liebe Grüße von

einem (positiv?) überraschten und verwirrten Jan

Sodele, bitte einmal das Userscript updaten: https://proxy.lss-manager.de/v4/lssm-v4.user.js

Im Dashboard unter "Gebäudeübersicht" steht bei der Leitstelle dran, wie viele maximal möglich sind. Ich bin mir aber nicht ganz sicher, ob da 100% richtig gerechnet wird (in Bezug auf Hubschrauber-Standplätze). Der Fuhrpark-Manager rechnet da aber auf jeden Fall richtig und ist eine gute Alternative!

Zitat von Teddybaer28121989

Und das gute, die beiden beißen sich noch nicht einmal.

Wir füttern unser Kind ja auch gut, so dass es niemanden beissen muss ?

=> LSS-Manager V.4