Mit ProxyWatch kann ich die Sekunden bis zum Absturz runterzählen, der ist deaktiviert.
Ich habe den ProxyWatch ausgeschaltet. Nun wird keine Verbindung mehr zum Stream aufgebaut. Es bleibt bei „Wird verbunden (ICE)“ stehen bis „Verbindung fehlgeschlagen“ kommt.
In der Konsole lässt sich die Vorschau des Streams problemlos öffnen.
ich bin aktuell im Urlaub, und fern der Heimat.
jetzt habe ich Angst meinen Kamera Stream zu starten, so das mir vielleicht mein Symcon abschmiert.
wenn das abschmiert, habe ich wahrscheinlich keine Möglichkeit aus der Ferne neu zu starten oder?
Je nachdem ob du SSH Zugriff hast. Aber den bräuchtest du ja auch, um das Update zu fahren
paresy
Leider habe ich das bis jetzt noch nicht in den Griff bekommen.
Proxywatch ist bei mir deaktiviert.
So sieht die Konfiguration aus.
Ich habe noch eine Kleinigkeit korrigiert, die in den letzten Tagen in den Crashlogs aufgetaucht ist. Freue mich über Feedback, ob es besser geworden ist @obala1983 @olima
paresy
Moin, ist in der neuen Testing zufällig auch direkt der Timeout gefixt?
Ich habe das update installiert. Bis jetzt sieht es gut aus.
Ist im Moment nur 1 Stream .
BTW. Seit ich auf die 7.2 testing gewechselt bin, lässt sich der Dienst (Windows) nicht mehr beenden. Ich muss den Task dann killen.
Oliver
Kannst du im Logfile schauen wo genau er stehen bleibt?
paresy
Zum Stream
Bei mir wird der Stream geladen und flüssig angezeigt. Nach ca. 2h hängt sich der Stream auf (Standbild). Nach Neustart der App läuft es wieder.
ZUm Dienst
das steht im Log am Ende:
06.08.2024 15:25:34 | 00000 | MESSAGE | Kernel | Beende Nachrichten-Thread…
06.08.2024 15:25:34 | 00000 | MESSAGE | Kernel | Beende Memory-Monitor-Thread…
06.08.2024 15:25:34 | 00000 | MESSAGE | Kernel | Speichere Einstellungen…
06.08.2024 15:25:34 | 00000 | MESSAGE | LicensePool | Removing…
06.08.2024 15:25:34 | 00000 | MESSAGE | CategoryManager | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | ObjectManager | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | VariableManager | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | ScriptManager | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | EventManager | Beende Ereignis Thread…
06.08.2024 15:25:34 | 00000 | MESSAGE | EventManager | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | LinkManager | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | ModuleLoader | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | FlowHandler | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | MutexHandler | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | ProfilePool | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | SyncRemoteService | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | SyncReplicationService | Removing…
06.08.2024 15:25:34 | 00000 | MESSAGE | Settings | Terminating settings thread…
06.08.2024 15:25:34 | 00000 | MESSAGE | Settings | Removing…
06.08.2024 15:25:34 | 00000 | MESSAGE | ScriptEngine | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | ScriptEngine | Warte auf Beendigung aller Skript-Threads…
06.08.2024 15:25:34 | 00000 | MESSAGE | TimerPool | Beende Timer-Thread…
06.08.2024 15:25:34 | 00000 | MESSAGE | TimerPool | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | DataServer | Entferne…
06.08.2024 15:25:34 | 00000 | MESSAGE | DataServer | Stoppe Server…
Oliver
Ich hatte die Probleme mit dem Beenden des Windows Dienstes auch schon.
Schau mal in Symcon unter PHP Informationen, ob ein Tread lange Zeit aktiv ist (rot).
Diese Treads konnten von Symcon jeweils nicht beendet werden und dann musste ich den Dienst auch killen.
Seitdem ich diese fehlerhaften Treads korrigiert habe kein Problem mehr.
Noch ein Grund können die Streams sein, wenn sie beginnen zu stocken.
Das wäre dann der Fall, wenn du denn Dienst deswegen neu starten musst.
Da musst ich den Dienst auch öfters killen.
Ich habe gestern die Auflösung und die Framerate des Streams deutlich reduziert. (640x360 bei 10fps). Nun lief der Stream bis heute morgen stabil. Der Delay liegt bei ca. 3 sec.
@mb-stern
Das mit den hängenden Threads hatte ich auch schon. Ist aber in diesem Fall nicht der Fall. Ich denke auch das es etwas mit den Streams zu tun hat.
Soeben ist der Dienst wieder gestorben (ProxyWatch ist aktiviert)
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | ice: video: connectivity check is complete (update=1)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | video: Dumping media state: ----- ICE Media <video> -----
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | local_mode=Full, remote_mode=Full, local_role=Controlling
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | local_ufrag="8RPgd12" local_pwd="XXXXXXX"
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | Components: (1)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | id=1 ldef=XX.XX.XX.XX:53455 rdef= concluded=1
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | Local Candidates: (2)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | {1} fnd=55d72032 prio=000000ff relay:XX.XX.XX.XX:53455 (rel-addr=XX.XX.XX.XX:53455)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | {1} fnd=509757fa prio=640000ff srflx:XX.XX.XX.XX:48784 (rel-addr=XX.XX.XX.XX:53455)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | Remote Candidates: (2)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | {1} fnd=candidate:4265529989 prio=64001eff srflx:XX.XX.XX.XX:58448
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | {1} fnd=candidate:2681525256 prio=02001fff relay:XX.XX.XX.XX:64903 (rel-addr=XX.XX.XX.XX:58448)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | Check list: [state=Completed] (1)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | {comp=1} Failed { } srflx:XX.XX.XX.XX:48784 <---> srflx:XX.XX.XX.XX:58448 (Connection timed out [110])
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | Valid list: (1)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | * {comp=1} Succeeded { VN} srflx:XX.XX.XX.XX:48784 <---> relay:XX.XX.XX.XX:64903
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | STUN debug:
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | STUN client transactions: (1)
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | method=Binding tid=2c764938f56a5e03ba43f3f4 rto=100ms tmr=100 n=1 interval=100
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | video: comp1 setting local: XX.XX.XX.XX:48784
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | stream: 'video' mnat 'ice' connected: raddr XX.XX.XX.XX:64903
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | mediatrack: ice connected (video)
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | stream: video: starting mediaenc 'dtls_srtp' (wait_secure=1)
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | dtls_srtp: media=video -- start DTLS server
10/08/24 10:03:35 | 00000 | DEBUG | VideoServer/VoIP | dtls_srtp: component start: RTP [raddr=XX.XX.XX.XX:64903]
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | ice: video: sending Re-INVITE with updated default candidates
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | peerconnection: medianat gathered (stable)
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | peerconnection: create offer
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | - - offer - -
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | v=0
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | o=- 2026093700 1999416052 IN IP4 127.0.0.1
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | s=-
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | c=IN IP4 127.0.0.1
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | t=0 0
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=ice-ufrag:8RPgd12
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=ice-pwd:XXXXXXX
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=setup:actpass
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=fingerprint:SHA-256 BB:2B:63:9B:48:E6:8C:B5:94:64:FE:58:99:D7:40:DF:DC:C8:A5:16:D9:07:00:BB:DB:97:E8:66:54:31:47:F7
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | m=video 48784 UDP/TLS/RTP/SAVPF 96 97
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | c=IN IP4 XX.XX.XX.XX
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=rtpmap:96 H264/90000
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=fmtp:96 packetization-mode=0;profile-level-id=42e01f
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=rtpmap:97 H264/90000
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=fmtp:97 packetization-mode=1;profile-level-id=42e01f
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=sendrecv
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=rtcp-rsize
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=ssrc:1204857617 cname:KVDug5FLJrUdHAV
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=framerate:30.00
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=rtcp-fb:* nack
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=rtcp-fb:* nack pli
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=rtcp-mux
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=mid:0
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=candidate:55d72032 1 UDP 255 XX.XX.XX.XX 53455 typ relay raddr XX.XX.XX.XX rport 53455
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=candidate:509757fa 1 UDP 1677721855 XX.XX.XX.XX 48784 typ srflx raddr XX.XX.XX.XX rport 53455
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=remote-candidates:1 XX.XX.XX.XX 58448 1 XX.XX.XX.XX 64903
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | a=fingerprint:SHA-256 BB:2B:63:9B:48:E6:8C:B5:94:64:FE:58:99:D7:40:DF:DC:C8:A5:16:D9:07:00:BB:DB:97:E8:66:54:31:47:F7
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | - - - - - - -
10/08/24 10:03:35 | 00000 | MESSAGE | VideoServer/VoIP | descr: encode: type='offer'
Moin Moin, bin auf der aktuellsten Stable und mein Panel schmiert mit Kamerastream viel häufiger ab als ohne.
Beispielscreenshot:
Unten links hab ich den rtsp Stream meiner Unifi Cam jetzt rausgenommen. Ohne läuft die Seite meist ohne Absturz von Morgens bis Abends durch. Ab und an mal ein komplett schwarzes Chrome Bild mit Fehlermeldung „Out of Memory“
Aber sobald ich ein rtsp Stream in mein Dashboard packe (ob nun medium oder high) stürzt das Dashboard nach mehreren Minuten bis wenigen Stunden ab. (auch kompletter schwarzer Bildschirm im Browser)
Ich versuch das jetzt noch mal genauer zu beobachten.
Da ist der Fehler schon… keine Stunde hats gedauert. Fehlercode: Out of Memory
Soll ich das ganze noch mal mit aktiviertem ProxyWatch nachstellen ?
IP-Symcon 7.2, Ubuntu (Docker) (amd64), 03.09.2024, cc3cf21ea602
Bei mir das selbe.
Es läuft manchmal echt super, die Streams bauen sich schnell auf.
Dann wieder mal sehr schleppend.
Mal stürzt der Dienst einfach ab.
In Firefox und Chrome das selbe.
Läuft auf IPS 7.2 stable unter Ubuntu 24.04.1 LTS auf Proxmox als Hoster.
Mich hat es jetzt auch erwischt. Bei allen Kamerastreams ein Ladekringel und Symcon schmiert komplett ab. Webfront und Konsole nicht mehr erreichbar. Den Dienst über die Symbox neu starten, funktioniert nicht, ich musste das Beenden erzwingen. Unschön!
Einmalig oder passiert es ständig?
paresy
Heute zum ersten Mal. Ich werde die Streams mal etwas mehr testen und berichten.
In der 8.0 sind definitiv alle uns bekannten Absturzursachen gelöst. D.h. Es muss irgendwas neues oder spezielles sein
paresy
bei mir auch seit heute, vorher immer stabil
beim anwählen der Streams nur der Kreis dann hängt sich der Dienst auf und muss gekillt werden. Heute schon zwei mal, vorher ewig nicht mehr…