Monatsrückblick Oktober 2026 ist online!

[typhos]

@Ephi Danke für das Video und den VLC-Test, damit ist das Bild jetzt ziemlich klar.

Ton über RTSP

Über stream.mp4 hörst du im VLC alle drei Kameras. Adapter und go2rtc liefern den Ton also. Dass er über RTSP fehlt, liegt am VLC: Er bekommt die Tonspur, spielt sie aber nicht ab. Nimm im VLC am besten den http-Link statt RTSP:

http://<IP-des-ioBroker>:1984/api/stream.mp4?src=<Seriennummer>

Ton der S340

In deiner Aufnahme ist eine Tonspur mit Inhalt, sie ist aber sehr leise. Der Grundpegel liegt bei etwa -65 dB. Zwischen Sekunde 4 und 8 und gegen Ende steigt er auf etwa -40 dB, die lauteste Stelle erreicht -26 dB. Bei normaler Lautstärke hört man davon kaum etwas. Dreh beim Abspielen der Datei einmal ganz auf: Hörst du dann etwas?

Grünes Bild und Schwarzbild

Dein Gefühl stimmt, die Auflösung ändert sich mehrmals. In der Aufnahme startet die S340 mit 1280x720, wechselt nach 4,1 Sekunden auf 1920x1080 und nach 8,3 Sekunden auf 2880x1616. Das passt zu deinen Beobachtungen: VLC über RTSP zeigt 4-5 Sekunden nach dem ersten Bild ein Schwarzbild, und über http wird das Bild für ein paar Sekunden grün und verpixelt. Die Kamera schickt die Bilder sauber, das habe ich Bild für Bild geprüft. Die Player kommen aber mit einer Auflösung, die sich mitten im Stream ändert, nicht zurecht.

Das passiert, wenn die Streaming-Qualität der Kamera auf „Auto“ steht. Die Pan&Tilt ist davon nicht betroffen, wahrscheinlich steht sie auf einer festen Qualität.

Abhilfe: Stell bei jeder S340 eine feste Qualität ein, entweder in der eufy-App oder im Objektbaum über den Datenpunkt video_streaming_quality der Kamera:

• 1 = HD (720P)
• 2 = Full HD (1080P)
• 3 = 3K HD

Die Einstellung „Livestream-Qualität“ in der Adapter-Konfiguration greift bei der S340 bisher nicht. Sie kennt nur Niedrig/Mittel/Hoch, die S340 benennt ihre Stufen aber nach der Auflösung. Ab der nächsten Version gilt sie auch für solche Kameras: Niedrig ist dann 720P, Mittel 1080P und Hoch 3K. Bis dahin hilft der Datenpunkt oder die eufy-App.

Sag gern Bescheid, ob mit fester Qualität das Schwarzbild und das grüne Bild verschwinden.

[Ephi]

@typhos sagte:

Abhilfe: Stell bei jeder S340 eine feste Qualität ein, entweder in der eufy-App oder im Objektbaum über den Datenpunkt video_streaming_quality der Kamera

Erst einmal vielen Dank. Das komische ist, dass sowohl in der Eufy-App als auch im Objektbaum die Qualität bereits fest auf 3K HD eingestellt ist. Ich kann dementsprechend hier nichts mehr verändern. Ich habe jetzt nochmals zunächst auf Auto und dann nochmals fest auf 3K HD umgestellt. Das Verhalten bleibt aber gleich...

[typhos]

@Ephi Danke fürs Nachsehen, dann lag ich bei der S340 falsch. Wenn sie schon fest auf 3K HD steht, erhöht sie die Auflösung beim Start jedes Livestreams offenbar selbst: erst 720p, dann 1080p, dann 3K. Am Adapter kann ich das nicht abstellen, und die Änderung an der Livestream-Qualität aus meinem letzten Beitrag hilft bei der S340 deshalb auch nicht.

Was helfen sollte: der Kompatibilitäts-Stream

Trag in der Adapter-Konfiguration unter „Geräte mit Kompatibilitäts-Stream“ die Seriennummern der beiden S340 ein. Dann rechnet go2rtc den Stream mit ffmpeg auf 720p H.264 um. ffmpeg kommt mit den Wechseln der Auflösung zurecht, und der Player bekommt durchgehend dasselbe Bildformat. Ich habe das mit deiner Aufnahme nachgestellt: Nach dem Umrechnen haben alle Bilder 1280x720.

Der Stream heißt dann <Seriennummer>_compat. Die Datenpunkte livestream und livestream_rtsp der Kamera zeigen danach automatisch darauf. Im VLC entsprechend:

http://<IP-des-ioBroker>:1984/api/stream.mp4?src=<Seriennummer>_compat

Zwei Einschränkungen:

• Das Bild hat dann nur 720p, und das Umrechnen kostet CPU auf dem ioBroker-Rechner, solange jemand zuschaut.
• In 3.5.0 kann ein Kompatibilitäts-Stream hängen bleiben, nachdem ein Player ihn geschlossen hat. Dann hilft nur ein Neustart des Adapters. Das ist für die nächste Version behoben.

Probier es gern aus und sag Bescheid, ob das grüne Bild und das Schwarzbild damit weg sind.

[Ephi]

@typhos sagte:

Probier es gern aus und sag Bescheid, ob das grüne Bild und das Schwarzbild damit weg sind.

Hab es gerade ausprobiert. In der Tat sind die Bildstörungen damit weg, allerdings kommt über den Kompatibilitäts-Stream jetzt kein Ton mehr. Habe es mehrfach gestartet, immer eindeutig ohne Ton, obwohl die Tonspur aktiviert ist im VLC-Player.

Edit: Wenn ich den normalen Stream wie bisher aufrufe ist der Ton eindeutig zu hören, nur halt mit den bekannten Bildstörungen.

Edit 2: Wenn ich den _compat-Stream im Browser öffne ist ein Ton zu hören, nicht jedoch im VLC-Player... Scheinbar hat der VLC-Player doch deutliche Probleme mit dem Ton, je nach Streamquelle. Schade, dass es offenbar keine Lösung gibt, bei der alle Probleme behoben sind. Oder hast Du noch eine Idee?

[typhos]

@Ephi Danke fürs Testen, das hat geholfen. Ich konnte das mit meiner eigenen Kamera nachstellen: Auch bei mir kommt über den Kompatibilitäts-Stream im VLC kein Ton.

Ursache: Beim Umrechnen beginnt das Bild 2 bis 4 Sekunden vor dem Ton. ffmpeg füllt den Anfang des Videos mit wiederholten Bildern auf, damit die Bildrate konstant bleibt. Danach laufen Bild und Ton im Stream die ganze Zeit um diesen Abstand versetzt. Der Browser puffert und spielt den Ton trotzdem ab, VLC verwirft ihn als zu spät. Beim normalen Stream gibt es den Versatz nicht, deshalb hast du dort Ton.

Behoben habe ich das, indem ffmpeg die Zeitstempel des Bildes so lässt, wie sie von der Kamera kommen. Damit liegen Bild und Ton bei mir wieder gleichauf, und der Kompatibilitäts-Stream hat weiterhin durchgehend 720p. Die Änderung kommt mit der nächsten Version, zusammen mit der Korrektur gegen das Hängenbleiben des Kompatibilitäts-Streams.

Bis dahin: Mit Ton und ohne Bildstörungen geht es nur über den Kompatibilitäts-Stream im Browser. Falls dir dort auffällt, dass der Ton nicht zum Bild passt, liegt das am selben Versatz und ist mit der nächsten Version ebenfalls weg.

[Ephi]

@typhos

Super, Danke für deine Mühen!

[JB_Sullivan]

Frage: Ist es möglich das man in der Instanz die Kameras abwählen kann die man nicht haben möchte?

Hintergrund: Ich habe mehrere Eufy Kameras, die über den Adapter bei Bewegung ein entsprechendes Bild liefern.

Mein Problem ist, das 3 der 4 Kameras bei mir zu Hause ständig irgendwelche Bewegungsbilder Bilder liefern und in den ioBroker Ordner schreiben. Das ist auch gut so und auch gewünscht.

Die vierte Kamera ist in meinem Wohnmobil, welches im Winterquartier steht, montiert. Da der Adapter aber die Bilder aller, über den Eufy Account verknüpften Kameras abholt, habe ich unnötigen Datentraffic im WoMo welches über eine Daten Sim Karte und mobilen Router die Verbindung zur Außenwelt herstellt.

Zu Hause als auch das WoMo haben jeweils einzelne ioB Installationen - also kein Master - Slave Betrieb.

Von daher würde ich es begrüßen, wenn man die Kameras die man nicht sehen möchte, abwählen könnte. Ist das vielleicht möglich?

[Bluefox]

@JB_Sullivan Soweit ich sehe, gibt es dafür im Moment keine Einstellung. Eine Instanz holt immer alle Geräte des Eufy-Accounts, mit dem sie angemeldet ist.

Was jetzt schon geht: In der Doku wird ohnehin ein eigener Eufy-Account für ioBroker empfohlen, für den man die Geräte in der eufy-App freigibt. Leg dir also für zu Hause einen eigenen Account an und gib dort nur die 3 Kameras von zu Hause frei. Für das Wohnmobil machst du dasselbe mit einem zweiten Account, der nur die Kamera im WoMo bekommt. Dann fragt jede ioBroker-Installation nur ihre eigenen Kameras ab, und über die SIM läuft nichts mehr für die Instanz zu Hause.

Eine Ausschlussliste für einzelne Seriennummern in der Instanz wäre trotzdem sinnvoll. @typhos, was meinst du dazu?

[typhos]

@Bluefox Ja, sehe ich auch so. Kann ich gerne mit einbauen - sollte keine große Änderung sein.

[typhos]

@JB_Sullivan @Bluefox Ist umgesetzt und kommt mit der nächsten Version.

In der Instanz gibt es dann unter den Haupteinstellungen das Feld „Ausgeschlossene Geräte“. Dort trägst du die Seriennummern der Kameras ein, die diese Instanz ignorieren soll. Für ausgeschlossene Geräte legt der Adapter keine Datenpunkte an, verarbeitet keine Ereignisse, lädt keine Bilder und baut keine Verbindung zu ihnen auf. Datenpunkte, die schon angelegt sind, löscht er beim nächsten Start.

Für dein Setup heißt das:

• In der Instanz zu Hause die Kamera im Wohnmobil eintragen.
• In der Instanz im Wohnmobil die drei Kameras von zu Hause eintragen. Damit holt das WoMo über die SIM keine Bewegungsbilder von zu Hause mehr ab.

Hängen Kameras an einer HomeBase, trag am besten die Seriennummer der HomeBase ein. Damit sind auch alle Kameras an ihr ausgeschlossen, und es gibt keine Verbindung zur HomeBase mehr. Schließt du nur einzelne Kameras einer HomeBase aus, kann die Bibliothek gelegentlich einen Fehler loggen, wenn die HomeBase etwas zu dieser Kamera meldet, zum Beispiel den Akkustand.

Die Seriennummern findest du in den Objekten des Adapters oder in der eufy-App unter den Geräteinformationen.

Der Weg von @Bluefox mit einem eigenen Eufy-Account pro Installation funktioniert genauso und geht auch schon jetzt.

[Ephi]

Hallo @typhos

Habe gerade die neue Version 3.6.0 installiert. Die Kompatibilitäts-Streams haben jetzt auch im VLC-Player Ton, vielen Dank dafür.

Allerdings scheitert ein wiederholter Aufruf eines _compat-Streams zeitweise (nicht immer) dann im VLC-Player. Im Log taucht dann folgende Fehlermeldung auf:

go2rtc: 15:51:20.747 ERR github.com/AlexxIT/go2rtc/internal/mp4/mp4.go:107 > error="streams: exec/rtsp\n[rtsp @ 0x7fff97b05590] method DESCRIBE failed: 404 Not Found\n[in#0 @ 0x7fff97b06850] Error opening input: Server returned 404 Not Found\nError opening input file rtsp://127.0.0.1:8554/T81XXXXXXXXXXXXX?video&audio&source=ffmpeg:T81XXXXXXXXXXXXX%23video%3Dh264%23width%3D-2%23height%3D720%23audio%3Dcopy%23raw%3D-fps_mode+passthrough.\nError opening input files: Server returned 404 Not Found\n"

Das betrifft bei mir nur die SoloCam S340 (Solar-Außenkamera).

Tritt dieser Fehler auf (aber auch, wenn ich zuvor einen _compat-Stream erfolgreich gestartet habe), lässt sich bei mir auch nicht mehr der Stream der Pan&Tilt-Innenkamera starten, welche nicht als Kompatibilitäts-Stream im Adapter hinterlegt ist. Eine Fehlermeldung taucht bei der Innenkamera im Log nicht auf.

Wenn ich alles als normalen Stream starte (und keine Kamera in der Liste der Kompatibilitäts-Streams hinterlege) tritt dieser Fehler nicht auf (allerdings habe ich dann die bekannten Bildfehler).

Edit: Manchmal sieht die Fehlermeldung auch so aus:

go2rtc: 16:05:18.108 ERR [exec] timeout source="exec:/opt/iobroker/node_modules/ffmpeg-for-homebridge/ffmpeg -hide_banner -v error -fflags nobuffer -flags low_delay -timeout 5000000 -user_agent go2rtc/ffmpeg -rtsp_flags prefer_tcp -i rtsp://127.0.0.1:8554/T81XXXXXXXXXXXXX?video&audio&source=ffmpeg:T81XXXXXXXXXXXX%23video%3Dh264%23width%3D-2%23height%3D720%23audio%3Dcopy%23raw%3D-fps_mode+passthrough -fps_mode passthrough -c:v libx264 -g 50 -profile:v high -level:v 4.1 -preset:v superfast -tune:v zerolatency -pix_fmt:v yuv420p -c:a copy -vf \"scale=-2:720\" -user_agent ffmpeg/go2rtc -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/1d86587901422d36cadfd832ecbf6517"

Edit 2: Dann taucht auch diese Meldung im Log auf:

go2rtc: 16:10:21.149 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:60236: write: broken pipe" 16:10:21.149 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:60240: write: broken pipe" 16:10:21.149 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:41208: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:41214: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:42578: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:42584: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:34284: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:38006: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:38014: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:45476: write: broken pipe" 16:10:21.150 WRN github.com/AlexxIT/go2rtc/internal/rtsp/rtsp.go:262 > error="write tcp 127.0.0.1:8554->127.0.0.1:34288: write: broken pipe"

Edit 3: bei weiterem Testen stellt sich heraus, dass auch Probleme vorliegen, wenn keine Kamera in der Liste der Kompatibilitätsstreams enthalten ist. Solange ich nur die Solocams S340 starte, ist alles okay, auch bei mehrfachen Versuchen nacheinander. Sobald ich dann versuche, den Stream der Innenkamera im VLC-Player zu öffnen, funktioniert dies ebenfalls nicht mehr, auch die S340-Streams lassen sich ab dem Zeitpunkt nicht mehr öffnen (erst wenn ich den Adapter reboote oder eine Zeit lang abwarte). Ich gehe vorerst wieder auf Version 3.5.0 zurück.

[JB_Sullivan]

@typhos - Vielen Dank für das extreme schnelle umsetzten dieser Idee - Adapter Version ist installiert und es funktioniert 1 A. Mal gucken, ob ich den Standby Traffic im WoMo dadurch ein bisschen runter bekomme. 👍👍👍👍

..... das mit dem zweiten Account wäre dann mein Fallback gewesen ...... aber so ist es doch viel einfacher, denn man hat eigentlich schon viel zu viele Accounts für alles mögliche.

[typhos]

@Ephi Danke für die Rückmeldung und die Logzeilen, damit ließ sich das gut nachstellen. Schön, dass der Ton jetzt da ist.

Hinter den Fehlern stecken zwei Ursachen. Beide sind in Version 3.6.1 behoben. Sie ist veröffentlicht und erscheint in Kürze im latest-Repository:

1. Erneuter Aufruf kurz nach dem Schließen. Schaut niemand mehr zu, beendet der Adapter den Livestream nach 10 Sekunden. Kam der nächste Aufruf genau in dem Moment, in dem die Kamera gerade beendet wurde, hängte er sich an den endenden Livestream und wartete danach auf einen neuen, den niemand gestartet hat – bis zu fünf Minuten. In dieser Zeit blieben auch alle weiteren Aufrufe hängen. Daher kommen die Meldungen „[exec] timeout“ und die vielen „broken pipe“ auf einen Schlag, wenn die fünf Minuten um sind. Jetzt startet der Adapter in dem Fall sofort einen neuen Livestream.

2. Langsamer Start der Kamera. Für den Kompatibilitäts-Stream wartete ffmpeg nur 5 Sekunden auf das erste Bild der Kamera. Die S340 braucht beim Aufwecken oft länger, dann scheiterte der erste Aufruf, und erst ein zweiter kurz danach lief. Die Wartezeit ist jetzt auf 30 Sekunden erhöht. Mehr geht nicht, weil go2rtc selbst nach 30 Sekunden aufgibt: Braucht die Kamera mehr als etwa 20 Sekunden bis zum ersten Bild, scheitert der erste Aufruf weiterhin. Öffnest du den Stream dann innerhalb von 10 Sekunden noch einmal, läuft er, weil der Livestream dann schon da ist.

Zur Pan&Tilt: Sie hängt wie die S340 an der HomeBase 3, und die HomeBase überträgt immer nur einen Livestream gleichzeitig. Solange go2rtc auf die S340 wartet oder sie abspielt, startet der Adapter die Pan&Tilt deshalb nicht. Das steht nicht als Fehler, sondern als Info im Log: „On-demand stream …: the station is busy with the livestream of … - not started“. Mit dem Hänger aus Punkt 1 konnte das bis zu fünf Minuten dauern.

Falls die Pan&Tilt mit 3.6.1 immer noch nicht startet, obwohl der S340-Stream geschlossen ist, schick mir bitte das Log dieser Minuten mit Loglevel „debug“.

[Ephi]

@typhos

Danke für deine Arbeit, ich gebe dann Rückmeldung.

[Ephi]

@typhos

Hab Version 3.6.1 jetzt installiert und damit funktioniert es schon viel besser als vorher, auch bei den Kompatibilitäts-Streams. Einzig wenn ich zu schnell von einer zur anderen Kamera wechsele und nicht ca. 10 Sekunden nach dem Schließen des vorhergehenden Streams warte kommt es zu Problemen, dann aber wieder richtig. Ab dem Moment geht solange wieder nichts, bis ich den Adapter neu starte oder ca. 5 Minuten warte. Ich habe mal die wichtigsten Meldungen aus dem Log hierher kopiert (durch den Log-Modus Debug hat er mir den ganzen Log mit sekündlich mehrfachen Einträgen vollgeschrieben, während ein Stream läuft):

go2rtc: 14:59:25.246 ERR github.com/AlexxIT/go2rtc/internal/mp4/mp4.go:107 > error="streams: exec/rtsp\n[rtsp @ 0x7fff08641590] method DESCRIBE failed: 404 Not Found\n[in#0 @ 0x7fff08642850] Error opening input: Server returned 404 Not Found\nError opening input file rtsp://127.0.0.1:8554/T81XXXXXXXXXXXXX?video&audio&source=ffmpeg:T81XXXXXXXXXXXXX%23video%3Dh264%23width%3D-2%23height%3D720%23audio%3Dcopy%23timeout%3D30%23raw%3D-fps_mode+passthrough.\nError opening input files: Server returned 404 Not Found\n"

[Object.debug] On-demand stream T81XXXXXXXXXXX65: the station is busy with the livestream of T84XXXXXXXXXXX25 - not started

go2rtc: 14:59:25.188 WRN [rtsp] error="streams: 503 Station busy - Wohnzimmer is streaming" stream=T81XXXXXXXXXXXXX

Wenn Du noch mehr brauchst lass es mich gerne wissen.

[typhos]

@Ephi Danke für den Test und die Logzeilen, die haben gereicht.

Was passiert: Nach dem Schließen eines Streams läuft der Livestream der Kamera noch 10 Sekunden weiter, damit ein Neuladen der Seite nicht jedes Mal die Kamera neu aufwecken muss. Öffnest du in diesen 10 Sekunden eine andere Kamera derselben HomeBase, startet der Adapter sie, obwohl die HomeBase noch den alten Livestream überträgt. Die Bibliothek, über die der Adapter mit der HomeBase spricht, beendet den alten Livestream dann nur bei sich, schickt der HomeBase aber keinen Stopp. Die neue Kamera liefert daraufhin nichts, und der Adapter versucht es bis zu fünf Minuten lang weiter. In dieser Zeit gilt die Station als belegt, deshalb die Meldung „the station is busy with the livestream of …“ und das „404 Not Found“ beim Kompatibilitäts-Stream der S340.

Wartest du die 10 Sekunden ab, hat der Adapter den alten Livestream schon selbst ordentlich beendet – deshalb geht es dann.

Ab Version 3.6.2 stoppt der Adapter den Livestream der geschlossenen Kamera sofort, sobald eine andere Kamera derselben HomeBase geöffnet wird, und startet die neue erst danach. Sie ist veröffentlicht und erscheint in Kürze im latest-Repository. Ich habe hier keine HomeBase mit mehreren Kameras, um das am echten Gerät nachzustellen – über eine Rückmeldung, ob der schnelle Wechsel damit klappt, würde ich mich freuen. Bis zum Update hilft es, nach dem Schließen 10 Sekunden zu warten.

Das Loglevel kannst du wieder auf „info“ zurückstellen.

[Ephi]

@typhos

Danke, ich gebe gerne Rückmeldung!

[Ephi]

@typhos

Habe 3.6.2 gerade ausprobiert. Solange ich innerhalb der Kompatibilitäts-Streams (also bei den Außenkameras Solocam S340) bleibe funktioniert es jetzt. Sobald ich aber danach innerhalb der 10 Sekunden auf die Innenkamera Pan&Tilt (kein Kompatibilitäts-Stream) wechseln will, kommt es wieder zu den o.g. Fehlern (derselbe Inhalt, deshalb verzichte ich auf nochmaliges vollständiges Posten des Logs). Bedeutet: Der Stream von der Pan&Tilt startet nicht, auch nicht bei mehrfachen Versuchen, und ab da klappt auch der Start der beiden anderen Streams (S340) nicht mehr; Fehlermeldungen: Station Busy + 404 wie oben dargestellt, auch Timeout ist wieder da. Mein Gefühl ist, dass bei einer Mischung von Kompatibiltäts- und normalem Stream (bei unterschiedlichen Kameras) es zu dem Fehlerbild kommt. Bleibe ich bei einer Art, scheint der Fehler nicht aufzutreten. Falls du doch alle Fehler im Log brauchst, sag gerne Bescheid.

[typhos]

@Ephi Danke für den schnellen Test – deine Vermutung mit der Mischung ist eine gute Spur.

Ich glaube allerdings, es liegt nicht am Kompatibilitäts-Stream selbst, sondern am Videoformat dahinter: Die S340 sendet H.265, die Pan&Tilt H.264. Seit 3.6.2 stoppt der Adapter beim Wechsel den alten Livestream und startet den neuen direkt danach. Die HomeBase schickt aber vermutlich noch einen Moment lang Daten der alten Kamera hinterher, und die Bibliothek, über die der Adapter mit der HomeBase spricht, prüft nicht, von welcher Kamera die Daten kommen. Der neue Livestream der Pan&Tilt würde dann mit dem Rest der S340 beginnen und als H.265 eingestuft. Die eigentlichen H.264-Bilder der Pan&Tilt passen nicht dazu, go2rtc bekommt nichts Abspielbares, und der Adapter wartet bis zu fünf Minuten weiter – in der Zeit ist die HomeBase belegt, daher wieder „Station busy“, „404“ und „timeout“ bei den S340.
Zwischen den beiden S340 fällt das nicht auf, weil beide H.265 senden.

Da ich hier keine HomeBase mit mehreren Kameras habe, kann ich das nur aus dem Code ableiten. Bevor ich eine neue Version veröffentliche, würde ich das gern mit deinem Log bestätigen. Könntest du den Wechsel S340 → Pan&Tilt noch einmal nachstellen und mir die Zeilen mit „On-demand stream“ ab dem Schließen der S340 bis etwa eine Minute danach posten (Loglevel „debug“ reicht wie zuletzt)? Mich interessiert vor allem, ob kurz nach

On-demand stream <S340>: <Pan&Tilt> takes over the station - stopping livestream

eine Zeile

On-demand stream <Pan&Tilt>: first picture 0 seconds after the request

(oder 1 Sekunde) kommt. So schnell wacht die Pan&Tilt nicht auf – dann wären das die Daten der S340, und die Erklärung passt.

Falls du Lust hast, auch den umgekehrten Weg zu testen: Ich erwarte, dass Pan&Tilt schließen und innerhalb von 10 Sekunden eine S340 öffnen mit 3.6.2 genauso hängen bleibt.

Eine Korrektur habe ich vorbereitet: Der Adapter wartet nach dem Stopp einer Kamera zwei Sekunden, bevor er eine andere Kamera derselben HomeBase startet – in der Zeit verwirft die Bibliothek die nachkommenden Daten noch. Bis dahin hilft es, nach dem Schließen gut 10 Sekunden zu warten.

[Ephi]

@typhos

Vielen Dank und entschuldige die späte Rückmeldung. Bin erst gerade von einer beruflichen Fortbildung zurückgekommen und bin heute Abend zu platt für den Test. Ich werde den Test aber morgen durchführen können.