Sehr viele Ideen hab ich zu dem Thema leider noch nicht, zumindest hatte ich den Fehler bei mir noch nicht (hab aktuell 4x Android und 1x iOS im Dauerbetrieb).
Habt Ihr SSL/TLS in Verwendung bzw. macht es einen Unterschied wenn Ihr das mal deaktiviert?
Hallo,
nein, kein SSL. Ich habe den Stream jetzt mal abgekoppelt. Sehen wir mal, ob bis morgen das Problem nicht mehr auftritt. Ich werde die gleiche Oberfläche dann auch mal unter IOS (Ipad Air 2) laufen lassen. Von der Leistungsfähigkeit sollte das keinen großen Unterschied machen. Bin mal gespannt, ob es dann wieder zu einem Absturz kommt.
Übrigens: bevor die Fehlermeldung auftritt, friert die App schon komplett ein - alle Bedienelemente sind nicht mehr aktivierbar.
Viele Grüße
Dirk
Das ist bei mir auch so, gleicher Fehler auf 3 unterschiedlichen Android Geräten.
Die App scheint dann augenscheinlich abgestürzt zu sein, der OK Button in der App funktioniert dann auch nicht mehr.
In meiner View im Hintergrund kann ich aber sehen, das die Zeitanzeige weiter aktualisiert wird, also die App scheint dann doch nicht ganz weg zu sein.
Zumindest die Zeit des Client scheint weiter aktualisiert zu werden, weitere Werte vom Server habe ich noch nicht beobachtet.
Kannst du da nicht ggf. einen Neustart der App einbauen, wenn eine gewisse Zeit keine Kommunikation zum IPS Server mehr besteht?
VG,
Doc
Die App friert (ohne Bedienbarkeit) schon dann ein, bevor der OK-Button der Fehlermeldung überhaupt erscheint. Uhrzeit hab ich keine - ist aber mal ein Hinweis. Ich werd’ mir mal eine Sekundenanzeige einbauen 
Ich werde mal das hier ausprobieren:
Ein Watchdog für Apps - mal sehen, wie das funktioniert. Macht natürlich nur Sinn, wenn der beschriebene Fehler nicht im Minutentakt auftaucht (wie gestern bei mir).
Dirk
Heute schon 3x das Pad mit dem Fehler ausgestiegen.
Die Uhrzeit in der View lief hier jedes Mal auch weiter, aber das ist dann die Zeit des Clients, welche in der View angezeigt wird.
Was mir aber noch aufgefallen ist, das bei mir mit dem HTTPExeption Fehler immer der IPSView Connect Dienst mit im Fehler genannt wird. Das habe ich bei den anderen Bildern hier nicht gesehen.
Ich muss das nächstes Mal noch mal ein Bild davon machen.
24 Stunden OHNE Stream haben das Problem beseitigt. Das ist natürlich nicht Sinn der Sache, zeigt aber den Auslöser.
Ich habe jetzt eine weitere Kamera (aus Unifi Protect) per RTSP-Stream dauerhaft eingebunden - bisher kein Ausfall.
Frage: haben die anderen „Leidtragenden“ auch einen Doorbird als Kamera? Oder sind das andere Kameras? Gibt es jemand, der einen dauerhaften Stream in IPSView eingebunden hat und unter Android KEINE Probleme hat?
Viele Grüße
Dirk
Wie hier mehrfach beschrieben, sind verschiedene Kamera-Hersteller im Einsatz.
Ich konnte heute Morgen zum ersten mal sehen, das die APP schon vor der Meldung eingefroren ist.
Es ließ sich dann hier nichts mehr bedienen, auch alle Element die von IPS aktualisiert werden wurden es zu diesem Zeitpunkt dann nicht mehr.
Außnahme ist die Zeitanzeige des Clients in der View, die lief wie oben schon angedeutet weiter.
Ich habe ein paar Außenkameras verschiedenen Typs als RTSP Stream eingebunden, die werden aber nur ganz sporadisch bei Bewegung als Popup eingeblendet, also nichts dauerhaftes.
Die App muss ich wegen diesem Fehler ca. 3x täglich neu starten.
@Brownson
Andreas, könntest du nicht temporär etwas einbauen, was die App neu startet, wenn die Verbindung zum Server nicht mehr gegeben ist? Zumindest zeitweise/abschaltbar bis das Problem näher eingekreist ist?
VG,
Doc
Schon verstanden… Meine Unifi-Kamera (trotz ähnlicher Auflösung) führt grade NICHT zu Problemen, der Doorbird schon. Nicht alle haben ihre Kamera-Marken kundgetan.
Ich hatte den Stream bislang relativ klein auf der Oberfläche - wie gesagt, keine Probleme. Jetzt hab ich ihn mal von der Fläche ungefähr auf die Fläche des alten Doorbird-Streams hochgezogen.
Effekt: deutlich verzögerte Reaktionsgeschwindigkeit (z.B. bei einem Auswahl-Button ca. 3 Sekunden vom Berühren bis zur Aktion).
was hast Du für ein Gerät, eventuell ist das ja einfach zu schwach um einen Stream dauerhaft anzuzeigen?
Btw: Streams laufen mittlerweile direkt über IP-Symcon, der Type der Kamera sollte aus diesem Grund eigentlich keine Auswirkung haben 
Ein Watchdog für die Kommunikation zum Server ist bereits vorhanden, wenn 5 Minuten keine Kommunikation ist, dann wird die Verbindung neu initialisiert.
Wie genau lautet die Fehlermeldung bei Dir?
Verwendest Du ViewConnect oder Fernzugriff?
Hintergrund: Ich hatte mal einen Fall da wurden am Server so viele Snapshot Änderungen generiert, dass der Client (die Amaxxx Dinger haben ja nicht gerade viel Power) diese nicht schnell genug verarbeiten konnten.
ViewConnect könnte in dem Fall eine Lösung sein
Hallo Andreas,
ich nutze nur den ViewConnect Dienst im internen LAN.
Das Problem habe ich auf den Am… Pads als auch auf einem Samsung Galaxy S7FE Pad mit 4GB Ram.
Das sollte eigentlich performant genug sein.
Ich mache mal ein Screenshot, wenn ich nicht aus Gewohnheit die App schon neu gestartet habe.
VG,
Doc
Ein Samsung Galaxy Tab A SM-T510. Ich teste das in Kürze gegen mein altes Ipad Air 2 (das mit dem Doorbird-Stream nie Probleme hatte). Vom Takt her sollte das Samsung mehr Leistung haben - bin mal gespannt auf den direkten Vergleich.
Welche Tablets habt ihr im Einsatz? Wäre gut, mal ein „Ranking“ zu starten, welche Hardwareleistung wohl nötig ist für einen Dauer-Stream.
das habe ich auch gerade im Auge zum Testen der App, wäre also gut wenn Du es dort nachstellen könntest
Eventuell auch mal alle Streams komplett abschalten, damit wir den Fehler eingrenzen können (habe zwar erst vor einigen Monaten ein Profiling der Streams gemacht und das Memory über viele Stunden getrackt, aber dann habe ich zumindest mal einen Anhaltspunkt).
Ansonsten kann auch HTML/Web den Client ans Limit bringen (speziell viele einzelne Steuerelemente wo überall ein eigenständiger Browser geladen wird).
Stream ausgeschaltet behebt das Problem nachhaltig. Ich habe derzeit zwei Tests am Laufen: die unveränderte View aber auf einem Ipad Air 2 und parallel auf dem Samsung der „Umweg“ über die Diskstation, aber ebenfalls als RTSP-Stream. Morgen früh weiß ich mehr.
Hi,
Ich habe meinen rtsp stream durch ein mjpeg ersetzt und seitdem keine fehler mehr.
Es ist ziemlich sicher rtsp. Schau dir das bild von hier vom user @Mkzetel an.
Du siehst den weissen rahmen mit der Fehlermeldung und ein stück drunter die zwei flächen mit den streams und darin ebenfalls eine exceptionmeldung.
Viele grüße
P.s. zu früh gesendet
Die meldung hatte ich auch,genau an der stelle wo mein stream ist.
Übrigens egal ob über diskstation oder direkt von der Kamera, fehler kam bei beiden Varianten
Hallo Andreas,
das Galaxy habe ich nur sporadisch im Einsatz, das ist nicht mein Wandpanel, aber auf dem ist der Fehler auch schon aufgetaucht.
Zu deiner Frage:
Ich habe in der auf dem Bild sichtbaren View keine HTML Seiten eingebettet. Was aber zwischenzeitlich aufpoppt, sind Popup’s mit einem RTSP Stream der Außenkameras, allerdings nur mit einer sehr geringen Auflösung vom 320x240 und jeweils nur ein Stream.
Ich habe aber auch den Eindruck, wenn ich einige Popup’s deaktiviere, das die Fehlerhäufigkeit geringer wird. Bei mir ist das aktuell ca. 3x täglich.
Was ich dir aber noch sagen kann, was mir gerade aufgefallen ist, das dann beide Wandpads gleichzeit nicht mehr reagieren, obwohl sie beide zwar die selbe Ansicht haben, aber es unterschiedliche Views sind. Erstaunlicherweise habe beide Pad’s sich diesmal von selber „geheilt“.
Das ist mir heute auch zum ersten Mal aufgefallen.
Hier noch mal ein Bild von einer Meldung, wenn die View komplett hängt und nur nach einem abschießen wieder läuft.
Manchmal bekomme ich auch die Meldung wie im 2. Bild zu sehen, nachdem IPSView hängen geblieben ist und neu gestartet wurde.
VG,
Doc
Hi,
Ich muss mich revidieren, heute nach knapp 3 tagen kam wieder auf einem tablet der fehler.
Viele grüsse
