Test Adapter rtspStream v0.0.x GitHub
-
@marc_el_k sagte in Test Adapter rtspStream v0.0.x GitHub:
@wendy2702 ich wusste nicht genau, wie man ein Log hier postet, daher als Bild. Es laufen 2 Streams, nur leider wird eben nur einer angezeigt.
ändere den Port für Kamera: Garage
8084 wird zu 99% schon verwendet.
Die derzeit benutzen Ports kannst du dir hier anzeigen lassen:
netstat -nlp -
Bin gerade über den Adapter gestolpert.
Funktioniert hervorragend um meinen Doorbird 1080p Stream auf meinem LGTV anzuzeigen wenn es klingelt.
Ich habs bei mir erstmal so eingebaut, dass "startStream" nach dem Klingeln für 5 Minuten auf true bleibt.
Die beste Lösung wäre natürlich, wenn der Webserver merken würde, dass jemand die Webseite geöffnet hat und entsprechend nur für die Länge des Besuchs den Stream aktiviert. -
Hallo, gibt es für den Adapter noch Support? Er wäre genau was ich suche, nur leider kommt wie schon sehr oft hier erwähnt nur ein kleines schwarzes Feld wenn ich den Stream anschauen möchte. Gibt es eine einfach Möglichkeit zu prüfen, was ffmpeg vom raspberry zurück liefert? Wäre sehr dankbar für Unterstützung.
-
@ht22 said in Test Adapter rtspStream v0.0.x GitHub:
Hallo, gibt es für den Adapter noch Support?
Wenn ich es richtig sehe ist dieser Adapter nicht in den Repositories gelistet und war es auch nie. Als ALPHA Tester der du ja offenbar bist bitte an den Developer wenden nur dieser wird / kann GitHub Installationen supporten da nur er weiß was denn da gerade auf Github liegt.
-
Der Vollständigkeit und als Info - NICHT als Kritik
Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten. GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird.
Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen.
Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird.
Und falls es irgendwie unklar ist:
ioBroker unterstützt folgende Arten von Installation:
-
aus dem STABLE Repository
Das sind Adapter Releases die keine groben Fehler aufweisen (sollten). Natürlich kann es auch dort Fehler geben, die Behebung davon obliegt dem jeweiligen Dev und kann ggF auch dauern.
-
aus dem LATEST Repository
Das sind Adapter Releases die neu erstellt wurden und nur rudimentär getestet sind - oft auch als BETA Releases bezeichnet. Releases aus dem LATEST sind primär für unsere zahlreichen freiwilligen Tester gedacht. BETA / LATEST Releases können durchaus Fehler aufweisen - auch wenn ich davon ausgehe dass jeder aintainer dies zu vermeiden versucht. Vom Einsatz auf produktiven Systemen wird abgeraten außer man braucht irgenein neues Feature (z.B. neues Gerät) unbedingt. Hier muss dann jeder Entscheiden was ihm wichtig ist.
-
direkt von GITHUB
Von Installationen direkt aus Giuthub wird definitiv abgeraten außer auf Anweisung des Maintainers und für den Fall dass man gemeinsam mit diesem etwas testen will. Details siehe oben.
-
direkt von npm
Diese Installation kann erforderlich sein, wenn man eine bestimmte Version installieren möchte / muss. Im Normalfall sollte man direkte npm Installationen ebenso meiden wie direkte GitHub Installationen - ausgenommen um z.B. zu einer bekannten Version downzugraden - obwohl hier wenigstens ein definierter Stand garantiert ist.
Adapter die NUR via npm und/oder nur via GitHub installierbar sind sollte man meiden - diese wurden nicht mal einem rudimentären Review unterzogen und sollten mit dem Attribut "vollständig auf eigenes Risiko verwenden" installiert werden. Hier empfiehlt es sich den Developer zu ersuchen eine Aufnahme in die Repos zu veranlassen. Wenn dieser darauf nicht reagiert sollte man von einer eher kurzen und unklaren Lebensdauer des Adapters ausgehen. Support meiner-/unsererseits für solche Adapter ist mit sicherheit minimalistisch.
@mcm1957 -
-
-
Ok danke für die Information. Gibt es dann zufällig eine einfache alternative zu diesem Adapter? Ziel rtsp stream auf einfache Weise in eine vis einbinden damit Kamera als Gegensprechanlage genützt werden kann. Danke
-
-
Das was die meisten machen ist der Umweg über MotionEye...
-
@bob-der-1 sagte in Test Adapter rtspStream v0.0.x GitHub:
Das was die meisten machen ist der Umweg über MotionEye...
ja, ich auch. allerdings lööpt das ding nur mehr auf uralt linux (proxmox VM). depricatet.
Go2RTC muss ich mir mal anlinsen. beim kurz drüberschauen hab ichs noch nicht begriffen.
raspis hätte ich zum testen mal frei, die neuen 3d-drucker brauchen keine mehr. -
@da_woody Wenn du keine Aufnahme brauchst (motionEye) dann ist go2rtc die bessere Lösung. Braucht kaum Ressourcen und läuft auf minimalster Hardware.
Mein CT hat 1 Prozessor, 2 GB Speicher und 4 GB Festplatte zugeordnet.
Speicher würde sogar 512 MB ausreichen und die CPU döst mit 2-3 % Auslastung vor sich hin. -
@chaot aufnahme ist mir schnurz! hab halt 9 cams die in iQontrol eingebunden sind.
mal linsen, wie ich da eventuell auf nen raspi, oder eine kleine lxc aufn server bringe...
-
Ich habe auch lange mit MotionEye herumgefummelt, allerdings nie stabile Streams in meine Vis bekommen. Permanent kam der Hinweis, dass Kameras nicht gefunden werden. In meinem Fall nehmen die Kameras selbst die Bewegung auf, sodass es mir lediglich um die flüßige Wiedergabe der Streams ging und dabei noch wenig Ressourcen verbauchen sollte. Mit dem Einsatz von Go2RTC bin ich seitdem maximal zufrieden. Es gibt auch eine Anleitung, dich ich damals noch etwas erweitert hatte.
