Streams in der neuen Visualisierung

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.

Ich hoffe die Probleme bekommt ihr bald in den Griff, wünsche euch gutes Gelingen.
Diverse Logs habe ich auch falls euch das helfen könnte.

VG Heiko

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.

Wie hast du das umgangen wenn ich fragen darf :wink:

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 :innocent:

1 „Gefällt mir“

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:-)

1 „Gefällt mir“

Moin,

Ich habe folgende beobachtung gemacht.

Ausgangssituation

  • Ein tablet welches drei streams dauerhaft in chrome darstellt
  • ein smartphone was hin und wieder von unterwegs, wie auch lokal eine visu anzeigt, welches ein stream besitzt.

In dieser konstellation ist es bei mir sehr stabil, ich bekomme die symbox nicht zum absturz.

Nun war urlaubszeit und ich habe das tablet, welches dauerhaft drei streams anzeigt, ausgeschaltet (steht im büro).

Ab da, stürzte die symbox zuverlässig ab, wenn man die visu mit dem smartphone geöffnet hat, aber schloss bevor der stream fertig geladen war.

Heute ist das büro wieder besetzt und seitdem kann ich keine abstürze mehr provozieren.

Vielleicht hilft das beim eingrenzen?

Viele grüße

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).

paresy

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.

paresy

Hi,

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.

Viele grüsse

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.

paresy

Hat bei mir leider nicht geholfen, per LTE (Connect) 2x Seite mit 4 Streams auf und zu und der Dienst ist abgestürzt.

IP-Symcon 7.2, Raspberry Pi (arm64), 29.07.2024, a55f287c8600

auch bei mir:
internes Netzwerk: Stream mit 4 Kamers 3x auf und zu und IPS stürzt ab
Verbindung über IPmagic: 2x auf und zu und IPS stürzt ab

IP-Symcon 7.2, Ubuntu (amd64), 29.07.2024, a55f287c8600

@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.

paresy

Hi,

folgende Teststellung

  1. Symbox neugestartet
  2. mich per gdb drangehangen
  3. drei Tablets ziehen einen normalen Stream per IPSView, ein Tablet lässt die Kachelvisu mit Chrome und drei streams anzeigen.
  4. ein Laptop wechselt permanent in Chrome die Visu, bis „Stream wird geladen“, mal wird abgewartet bis geladen wird, mal vorher die Seite gewechselt,
  5. 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 :wink:

Viele Grüße

So, Symbox ist abgestürzt…

Aber ich habe keine Daten rausbekommen

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

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 :smiley:

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. :slight_smile: Das macht ja Hoffnung, dass wir auf dem richtigen Weg sind.

paresy

Also ich habe, als GDB mit dem SIGABRT abbrach die Methode B verwendet.

Nun habe ich seit über einer Stunde mit Methode A symcom am laufen. Ich habe gefühlt 100x hin und hergeschaltet. Alles läuft bei mir.

Ich gebe es für heute auf :wink:

1 „Gefällt mir“

Moin,

grundsätzlich habe ich damit kein Problem - ich weiß nur nicht, was du mit GDB meinst :wink:
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.

So gestresst wie kris habe ich das System nicht :slight_smile:

Moin,
ist bei mir leider eher schlecht heute.

Kann aber mal zwischendurch selber versuchen GDB nach deinem Beitrag ans laufen zu bringen und dir dann die log senden.

@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 :slight_smile:

paresy

Neues Update, in dem vermutlich das Problem von @bgersmann gelöst sein wird.

paresy