Problem mit Longpoll seit FTUI 2.4

[setstate]

Das ist der longpoll. Blödsinnigweise sendet FHEM bei jedem Event die ganze Liste immer wieder neu, nicht nur die neue Zeile. Man muss sich dann merken, in welcher Zeile man war und nur die neue Zeile rausfiltern.

Vermutlich kannte der Entwickler des FHEM Event Viewer die Append Funktion damals noch nicht und tauscht immer den kpl. Inhalt aus. Das führt unweigerlich zum Überlauf. Als Worksround starte ich longpoll aller 9999 Zeilen neu, um diesen Überlauf zu vermeiden.

[Waldmensch]

Nach ziemlich genau einer Stunde wird dieser request neu gestartet.
Was ich aber im Heap Snapshot festgestellt habe, ist das der Speicherverbrauch permanent ansteigt und das Delta neue Objekte/ zerstörte Objekte positiv ist. Irgendwas ist da im Argen, das der Garbage Collector nicht abräumen kann. Mach dir mal den Spaß und geh in der DEV Konsole auf Profile und mach im Stundentakt Snapshots. Dort den Filter auf Comparison. Ganz deutlich tritt (String) hervor.


Gesendet von iPhone mit Tapatalk

[setstate]

Habe ich noch nicht intensiv gemacht. Siehst du ein bestimmtes Object, was anwächst?
Ist ein wichtiger Punkt, den wir lösen müssen.

[Waldmensch]

Dieser Snapshot ist gemacht, nachdem der longpoll neu gestartet wurde. Man sieht, das 3MB freigegeben worden. Allerdings wird (array) immer größer bis zum pagerefresh. beim Array ist der hauptfresser das Chart, was ja auch logisch ist.

Edit: wobei es nicht logisch ist - die im Chart angezeigten Daten sind ja nach einem Pagerefresh genauso da, also müsste das array genauso groß sein wie vor dem refresh

[Waldmensch]

Ich habe mal markiert, was mir komisch vorkommt. Von dem eingekastelten gibt es hunderte

[setstate]

Okay, Chart muss sich eki ansehen.

[Waldmensch]

Das ist halt schwer mit Screenshots zu erklären. Ich habe auch keine Ahnung ob ich da auf der richtigen Fährte bin. Ich kann es mir nur so erklären, dass das Werte Array jedesmal neu erstellt wird und das alte irgendwo hängenbleibt. Eventuell kann man ja neue Werte einfach nur in das bestehende Array einfügen.


Gesendet von iPhone mit Tapatalk

[Garbsen]

Moin

Nachdem bei mir mittlerweile Tabletui in Safari auf dem iPad2 sich schon nach wenigen Minuten verabschiedet, habe ich eine Datensicherung eingespielt, oder korrekter lasse jetzt auf dem iPad die Tabletui Seite aus einem Ordner mit Version 2.4 anzeigen. Und siehe da, kein Absturz mehr.
Von daher die starke Vermutung, dass es an 2.5 liegt.
Ich werde aber auch noch schauen, was ich evtl. In der 2.5 Version der Seite sonst geändert hatte und dies (soweit es nicht 2-5 spezifische Anpassungen waren) in der 2.4 Version entsprechend vornehmen, um auszuschließen dass der Fehler da liegt.

[Garbsen]

Update:
Bei mir liegt das Absturz Problem offenbar am Widget iFrame

Wenn ich die Kameras hiermit einbinde, beendet sich Safari auf dem iPad2 wie dargestellt nach kurzer Zeit.

Eingebunden habe ich es wie folgt:

Code Auswählen Erweitern

            <div data-type="iframe"                     

data-check="false"
data-icon-spinner="fa-spinner fa-spin"
data-color-spinner="#aa6900"
data-icon-error="fa-frown-o"
data-color-error="#505050"
data-scrolling="no"
data-timeout="20000"
data-fill="no"
data-height="350"
data-width="450"
class=""
data-src="http://192.168.5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&cameraId=1&format=mjpeg&_sid=%xxxxxx%22" data-size="10%">
                     
                      </div>

Binde ich den gleichen Link per Image Widget ein, läuft alles stabil

[setstate]

Probiere mal beim iFrame data-check="false"

[Garbsen]

Probiere mal beim iFrame data-check="false"

Habe ich doch, oder übersehe ich ein typo?

[Eisix]

Hallo,

So wie es aussieht habe ich das Problem auch mit Android Geräten. Initialen Load hängt sich beim Longpoll auf. Nach einer Weile wird dann alles geladen. In unregelmäßigen Abständen hängt sich dann die Seite komplett auf und ich muss den Browser neu starten.

Gruß
Eisix

[Garbsen]

Update:
Bei mir liegt das Absturz Problem offenbar am Widget iFrame

Wenn ich die Kameras hiermit einbinde, beendet sich Safari auf dem iPad2 wie dargestellt nach kurzer Zeit.

Eingebunden habe ich es wie folgt:

Code Auswählen Erweitern

            <div data-type="iframe"                     

data-check="false"
data-icon-spinner="fa-spinner fa-spin"
data-color-spinner="#aa6900"
data-icon-error="fa-frown-o"
data-color-error="#505050"
data-scrolling="no"
data-timeout="20000"
data-fill="no"
data-height="350"
data-width="450"
class=""
data-src="http://192.168.5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&cameraId=1&format=mjpeg&_sid=%xxxxxx%22" data-size="10%">
                     
                      </div>

Binde ich den gleichen Link per Image Widget ein, läuft alles stabil

Zu früh gefreut, über Nacht hat sich Safari dann auch trotz Einbindung per Image Device aufgehängt.
Aber immerhin deutlich stabiler als bei Einbindung per iFrame.

Ich bin leider nur ambitionierter Anwender, aber denjenigen hier mit mehr Ahnung hilft es vielleicht, dass der Absturz bei Einbindung per iFrame innerhalb kurzer Zweit (weniger als 60 Minuten) kommt und bei Einbindung per Image erst nach einigen Stunden.
Vielleicht könnt ihr analysieren welchen Unterschied es bei den beiden Widgets in Speicher Belegung gibt und damit den Fehler einkreisen.

Beste Grüße
K-H

[PatrickR]

Mahlzeit!

Mal eine kurze Zwischenmeldung zu meinem Problem. Ich habe festgestellt, dass - nur nachts - direkt beim Start und reproduzierbar folgender JScript-Fehler erscheint:

Code Auswählen Erweitern


#index_main.php:1
SyntaxError: Unexpected token < in JSON at position 0

Ich konnte das Problem schließlich auf das departure-Widget zurückführen, was seinerseits auf ein HTTPMOD-Modul zugreift. Im zugehörigen Reading stand ein Unicode-Zeichen (ein ü), welches zu der JSON-Fehlermeldung geführt hat.

Wichtig hierbei:

Code Auswählen Erweitern

curl -s "http://fhem:8083/fhem?cmd=jsonlist2&XHR=1" | python -m json.tool
wirft keinen Fehler.

Ich habe die Umlaute nun durch eine HTML-Entity ersetzt und die Fehlermeldung kommt nicht mehr. Nach dem Aufruf der Seite aktualisieren sich die Werte zumindest bei meinen Tests aber trotzdem, d. h. es ist noch nicht klar, ob mein ursprüngliches Longpoll-Problem gelöst ist. Ich werde das beobachten.

Das Problem tritt übrigens nur nachts auf, da nur nachts der Umlaut in der Abfahrtsliste auftaucht.

Patrick

[setstate]

Ich habe heute entdeckt, FHEM kann jetzt auch von Haus aus WebSocket 

Das baue ich doch gleich in eine FTUI 2.6

Meine altes Android-Tablet kann das zwar noch nicht, aber für alle modernen Geräte ist das bestimmt ein hoher Gewinn an Zuverlässigkeit und Stabilität.

Umlaute im JSON sind natürlich weiterhin ein Problem. Sowas muss natürlich HTML konform abgeschickt werden.