Ich habe auch seit der Umstellung auf die TileVisu entsprechende Probleme, welche ich im Webfront zuvor über ONVIF Stream des entsprechenden Moduls nie hatte.
Ich nutze aktuell 4 Foscam FI9902P Kameras nun über RTSP und habe generell leider ebenfalls regelmäßige Abstürze. Mit der 7.2 Test wurde es bereits etwas besser, dennoch stürzt der Dienst so oft ab, das ich die TileVisu somit als nahezu unbrauchbar erweist, obwohl mich die wirklich in Punkto Design und den Möglichkeiten total abholt. Ich will gar nicht mehr auf die alte Visu zurück, aber aktuell ist es unter diesem Umständen keine Option, da viele Komfortfunktionen, Logs, Sicherheitsfunktionen etc… über den Dienst laufen. Symcon läuft bei mir auf Windows 7.
Als Wandtablet nutze ich ein Amazon Show15 (leicht modifiziert, da der Browser an dem Teil sich immer nach 10Min. automatisch geschlossen hat). Mit den nun neueren Update 7.2#607 zeigt er mir nun auf dem Silk Browser an, dass der H264 Codec nicht abgespielt werden kann, bei der Version zuvor wurden meine Streams noch einwandfrei dargestellt (wenn nicht der Dienst wieder abgestürzt ist:-)).
Habe nun wieder ein Downgrade vorgenommen.
Da gibts leider immer noch keine finale Lösung, habe das Problem auch. Ich kann es aber umgehen, indem ich auf einer Seite mit Streams immer kurz warte, bis sich die Streams vollständig aufgebaut habe, bevor ich zur nächsten Seite wechsle.
ich behelfe mir aktuell damit, dass ich einen Snapshot jede 2 Sekunden anlege und den in der Visu einblende - ist dann quasi wie ein Video und ich habe ebenfalls ein Echtbild.
Damit stürzt der Dienst nicht ab, da es kein Videostream ist - zurück auf das alte WebFront ist nämlich keine Option
Ist zwar jetzt hier offtopic, aber ich habe per ECHOREMOTE eine Alexa Routine am laufen, welche über ein zyklisches Ereignis aus Symcon die Routine von Alexa im 5 Minuten Takt triggert. Dementsprechend bleibt nun immer der Browser aktiv, da die Routine (ausgelöst aus Symcon) immer den Browser über die Alexa Routine - mit dem Befehl „Alexa, öffne Silk“ aktiviert.
Da Alexa aber immer dies sprachlich bestätigt und da es zudem leider keinen Erfolg bringt, innerhalb der Alexa Routine vor/nach dem Befehl „Alexa, öffne Silk“ die Lautstärke zuvor auf Stumm zu schalten oder Null zu regeln, habe ich den Lautsprecher abgeklemmt an dem Tablet:-)
Mittlerweile können wir das Problem hier ebenfalls sehr gut nachstellen. Es passiert definitiv sehr zuverlässig, wenn man den Stream beendet (quasi beim Seitenwechsel). Noch einfacher/wahrscheinlicher wird es, wenn die Latenz höher ist (quasi von Remote oder per VPN).
Ab sofort ist eine neue 7.2 verfügbar. Ich würde mich sehr über eueren Test freuen, ob es damit besser geworden ist oder die Abstürze sogar ganz weg sind.
gerade auf meine symbox installiert und wild getestet dabei ist die symbox abgestürzt.
Es ist aber, zumindest bei mir, deutlich besser geworden. Zum testen habe ich smartphone (ein stream) und tablet (drei streams) gleichzeit die symbox maltretiert.
Wenn es hilft kann ich morgen einen dump erstellen.
Das wäre klasse! Wir haben hier auch sehr wild getestet und konnten es nicht mehr zum Absturz bringen. Somit wäre jeder Hinweis, an welcher Stelle er abstürzt, super.
@bgersmann@sunnyww Hätte einer von euch Morgen Zeit, sodass wir gemeinsam kurz per GDB dem Problem auf die Pelle rücken? Auf meinem System kann ich mit 3 Kameras egal ob intern oder per Connect keinen Absturz mehr provozieren.
drei Tablets ziehen einen normalen Stream per IPSView, ein Tablet lässt die Kachelvisu mit Chrome und drei streams anzeigen.
ein Laptop wechselt permanent in Chrome die Visu, bis „Stream wird geladen“, mal wird abgewartet bis geladen wird, mal vorher die Seite gewechselt,
Ein Smartphone öffnet die Visu in der App, mal mit, mal ohne Connect. Mal bis der Stream geladen ist, mal wird vorher die Seite gewechselt oder die App geschlossen.
Meine Beobachtung:
nach einen Zeit lang wird an am Smartphone in der App ein Stream nicht mehr angezeigt. Das Bild bleibt schwarz. Man sieht zwar im hintergrund, das etwas geladen wird, aber das Bild bleibt schwarz.
Auch ein Wechsel der Visu bringt kein Bild. Nach einer Wartezeit (ca 3-5 min) geht es aber wieder.
Zeitgleich ist der Stream aber am Laptop und an den Tablets zu sehen.
Ich kann das unter Chrome auch auf dem Laptop provozieren, einfach schnell zwischen den Kachelvisus wechseln, auch hier, nach 3-5 min geht es wieder.
Aber… Kein Absturz! Gestern war das anders. Ich versuche heute abend nochmal einen Absturz zu provozieren. Vielleicht braucht er nachdem Neustart eine Weile bis der Speicher voll wird
Das ist tatsächlich möglich. Für den Verbindungsaufbau (ICE) gibt es nur eine bestimmte Anzahl an Slots. Und wenn man zu viel hin und her schaltet, dauert es eine Weile, bis diese ggf. im Timeout enden und wieder frei sind. Das kann man sicherlich mal konfigurierbar machen (=erhöhbar), aber aktuell würde ich das als kosmetisches Problem ansehen
Sicher, dass GDB noch sauber aktiv war? Kannst du es noch einmal provozieren?
Es freut mich aber, dass es scheinbar wesentlich unwahrscheinlicher geworden ist und mehr Aufwand bedeutet, bis ein Absturz getriggert wird. Das macht ja Hoffnung, dass wir auf dem richtigen Weg sind.
grundsätzlich habe ich damit kein Problem - ich weiß nur nicht, was du mit GDB meinst
Könnte dir auch wieder die TeamViewer-Umgebung zur Verfügung stellen, dann könnt ihr selbst aktiv testen, wobei ich sagen muss, dass mit dem gestrigen Update bis Stand jetzt nichts mehr passiert ist.
@bgersmann Gerne. Wir können auch gerne einen anderen Tag nehmen, falls das bei dir nicht klappen sollen mit GDB. Schreib mir gerne eine PM sobald es bei dir passt