[RaHe67]

Hallo,
ist die Lösung dieses Problems eigentlich in die 5.4 Stable gewandert (falls es eine Lösung gab, überblick ich das hier irgendwie nicht)?
Ich frage, weil ich momentan mit meinen beiden Clients ein Ähnliches Problem erfahre. Das Live Bild beider Clients (siehe Signatur) friert manchmal alle 10 Sekunden ein, manchmal laufen sie problemlos.
Wenn das passiert, bricht die Verbindung von beiden streamdev-clients gleichzeitig zum Server ab.

Client-Log (auf beiden)

Code: [Select]

Apr  9 20:01:49 MLD user.err vdr: [2170] ERROR: streamdev-client: Couldn't connect to 192.168.2.4:2004: Connection timed out
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (0)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (1)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (2)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (3)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (4)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (5)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (6)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (7)
Apr  9 20:01:54 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (8)
Apr  9 20:01:55 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (9)
Apr  9 20:01:55 MLD user.err vdr: [21392] cStreamDevice::GetTSPacket: GetChecked: NOTHING (10)
Apr  9 20:01:55 MLD user.err vdr: [21353] cStreamdevFilters::Action(): stream disconnected ?
Auf dem Server habe ich keine Probleme im Messages log gefunden.

Edit: Hier nicht auf Raspberries sondern auf X86 Hardware!!!

Ralf

[clausmuus]

Bei dem hier diskutiertem Problem, ging es aber nur um Fehler beim Umschalten, nicht beim normalen Schauen. Oder habe ich jetzt was übersehen?

[RaHe67]

... , ging es aber nur um Fehler beim Umschalten, nicht beim normalen Schauen. Oder habe ich jetzt was übersehen?

Vermutlich nicht, wie oben geschrieben (und siehe Signatur) habe ich ja im Gegensatz eine Umgebung nur mit X86 Servern / Clients. Auch tritt das Problem nicht beim Kanalumschalten auf (das Bereinigt das Problem wieder), sondern manchmal, wenn ein anderer Client (z.B. DD-TV, also kein Streamdev) sich einen neuen Tuner auf der Octopus greift. Dann werden alle Streamdev Clients rausgeworfen.

Ist hoffentlich nicht einfach ein schnödes/temporäres Netzwerkproblem - wüsste momentan auch nicht wie ich das so einfach herausfinden könnte.

Die Symptome (in Form von logs) sehen nur ähnlich wie das Problem des original Posts aus. Mal kann ich es minutenlang nachvollziehen, manchmal tritt es länger nicht auf.
Obwohl, beim Starten der VDR-Clients (kompletter neuboot) bekomme ich es eigentlich immer genau 1x, ca. 10 Sekunden nach Anzeigen des ersten Live-Bildes friert es ein oder wird schwarz. Der Tuner lock ist dann wieder weg. ==> Kanal wechseln und es geht wieder (meistens für länger).

Ralf

[clausmuus]

Das klingt für mich jetzt danach, dass Du mehr Clients an der ONet hängen hast, als diese Tuner hat, bzw. das die Clients insgesamt mehr Tuner nutzen als verfügbar sind.
Dabei müssen noch nicht mal alle Tuner belegt sein. Beim umschalten wird gerne ein neuer Tuner bei der ONet genommen. Wenn keiner mehr frei ist, wird irgend einem Gerät einer weg genommen.

[RaHe67]

Hmm, eigentlich nicht.
Ich habe 2 VDR clients die über streamdev-client jeweils 1 Stream-Verbindung aufbauen.
Der Server ist für 3 SAT-IP Tuner konfiguriert. Mit dem DD-TV habe ich versucht vom Desktop zusätzliche Last (1 Tuner) zu erzeugen.
Eine Belegung von mehr als 3 von meinen 4 Empfängern sehe ich aktuell bei mir nicht (eventuell mit Aufnahme-Timern).

Ralf

[clausmuus]

Der Server dem 3 satip Tuner zugeordnet bekommen hat, wird diese auch nutzen, auch wenn keine Aufnahmen laufen. Zwar nur sporadisch, für EPG-Scans, aber das reich schon.
Wenn Du auf den Clients tatsächlich nur einen Tuner Konfiguriert hast (Voreinstellung sind 2) dann sind das zusammen bereits 5 Tuner. Ein Konflikt tritt da also sicher irgendwann auf. Bei mir tritt der bei einer ähnlichen Konfiguration schon wenige Minuten nach dem Start des Clients auf, auch ohne das der Server etwas aufnimmt.
Genau aus dem Grund empfehle ich bei solchen Konstellationen die Clients per Streamdev zu betreiben und dem Server alle Tuner zuzuordnen. Dann gibt's bei vier Tunern nahezu keine Konflikte mehr und vor allem keine Störungen.

[RaHe67]

Hab mich vielleicht nicht klar ausgedrückt ...

Dein Vorschlag ist genau mein Szenario bei dem sich das oben beschriebene Fehlerbild ergibt.

Der Server hat 3 Tuner zugeordnet. Die beiden VDR Clients verbinden sich nur über Streamdev-Clients (Einstellung eine gleichzeitige Verbindung oder so ähnlich im Streamdev, um zu verhindern, dass ein Streamdev Client mehr als einen Tuner über den Server belegen kann).

Aufnahmen werden nur auf dem Server gefahren.
An der Octopus kann ich sehen, welche IP den Tuner belegt - das ist immer nur der Streamdev-Server.

Einen Tuner habe ich als Reserve behalten, wenn ich anderweitig von anderen Systemen zugreifen will.

Ralf

[clausmuus]

Wie ist die ONet denn mit dem LNB verbunden.

[RaHe67]

Über einen 8-Kanal Spaun Multischalter.
4 Kanäle, also nicht kaskadiert.
Dvb-T bzw. DVB-C benutze ich nicht.

Am Spaun Multischalter hängen 2 "schielende" LNBs für Astra 19.2 und Hotbird 13.0

Gruß Ralf