MLD-5.x > General

Gelöst: Mehrere Probleme im Server-Client Szenario (RemoteOSD,Shared Recordings)

(1/5) > >>

RaHe67:
Erstmal Frohe Weihnachten an alle!

Kaum bin ich im Form angemeldet komme ich als "Einstieg" auch schon mit dem ersten Problem ;-)

Als Urlaubsprojekt habe ich mir in den Kopf gesetzt meinen liebgewonnenen VDR (reiner Client, YAVDR) in eine Server-Client Installation per komplettem Neuaufsetzen zu erweitern. Letztendlich bin ich jetzt bei MLD gelandet, da mir das Konzept am weitesten entgegenkommt.
Überzeugt hat mich (als Windows-Experte aber Linux Dilettant) dabei die einfache Webkonfiguration und ich habe mich an ein fortgeschrittenes Szenario gewagt (siehe auch Signatur). Mittlerweile hänge ich an mehren Problemen auf mehreren Ebenen, die zwar ansatzweise z.T. hier im Forum schon mal besprochen wurden aber letztendlich für mich nicht zur Lösung geführt haben.

Also fange ich einfach mal mit dem Ersten an:

Ich betreibe hier:

Sat-IP Server: DD Octopus NET V2 Max M4  (192.168.2.33)
Server: OMV4 + VirtualBox + MLD5.4-Stable (Server) (192.168.2.3, 192.168.2.4)
Client: MLD5.4-Stable (Client) (192.168.2.50)

Für beide MLD Instanzen ist das VDR-SATIP-Plugin aktiviert und gibt auch Empfang. Allerdings werden beide Logs durch die folgenden Fehler (mehrfach die Sekunde) geflutet:

Dec 26 15:24:00 (MLD) user.err vdr: [16429] SATIP-ERROR: Connect failed [device 0]
Dec 26 15:24:00 (MLD) user.err vdr: [16432] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.2.33/ [device 1]
Dec 26 15:24:00 (MLD) user.err vdr: [16432] SATIP-ERROR: Connect failed [device 1]
Dec 26 15:24:00 (MLD) user.err vdr: [16429] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.2.33/ [device 0]
Dec 26 15:24:00 (MLD) user.err vdr: [16429] SATIP-ERROR: Connect failed [device 0]

Sowohl auf dem Server als auch dem Client ist das SAT_IP Plugin auf Betriebsart niedrig eingestellt. Ich sehe jedoch ziemlich häufig dass alle 4 Tuner auf der Octopus belegt werden. Obwohl auf dem Client der EPG Daemon abgeschaltet ist und keine Timer anstehen.

Wie werde ich diese Fehler los und wie erreiche ich Kontrolle darüber wann sich welcher Tuner gegriffen wird?
Ziel ist es eigentlich dass nur der Server die Tuner (für Aufnahmen + EPG) belegt und der Client maximal einen Tuner oder noch besser einen Server Kanal streamed. Mit dem Streamdev-Client bin ich da leider auch noch nicht weitergekommen.

Viele Grüße

Ralf

clausmuus:
Hi,
optimal wäre für Dich wohl, wenn Du einen streaming Client installierst. Denn dann kannst Du dem Server alle satip Devices zuweisen und er kann die optimal verwalten (also auch bei bedarf mehrfach benutzen).
Wenn Du auch auf dem client satip verwendest, musst Du bedenken, das die Anzahl der insgesamt zugewiesenen dvb Devices nicht die Anzahl der verfügbaren übersteigt. Wenn Du dem Server also z.B. 3 dvb Devices zuweist, darf der Client nur noch höchstens eines benutzen. Und genau da scheint das Problem zu liegen. Ich habe das zwar noch nicht endgültig analysiert, aber ich habe die Vermutung das das satip Plugin immer mindestens 2 Devices belegt, auch wenn eingestellt ist, das nur eines verwendet werden soll. Das führt dann zu Konflikten auf dem satip Server und zu den von Dir geschilderten Fehlermeldungen. Die Fehlermeldungen sollten also ausbleiben, wenn Du auf Beiden Geräten einstellst, das zwei dvb Devices verwendet werden sollen.
Der Server wird immer alle satip Devices belegen, die Ihm zugewiesen sind, da dieser ständig mit allen freien (nicht für Aufnahmen benötigten) Devices EPG Scans durchführt.

RaHe67:
Ja danke Claus, das würde das Verhalten erklären. Habe jetzt das SAT-IP Plugin auf clientSeite entfernt: Der Server zieht auf der Octopus immer noch 4 Streams permanent an, bei live schauen vom Client (1 Kanal) und keine Aufnahmen aktiv.

Die SAT-IP Fehler sind jetzt weg.

Habe allerdings noch Probleme mit der streamdev-client Verbindung, deshalb hatte ich auch noch das SAT-IP-Plugin auf der Client Seite eingebunden.
Grundsätztlich funktioniert die Verbindung zum Streamdev-server. D.h. das Live Bild ist da. Die Steuerung des Servers über RemoteOSD ist allerdings instabil.

a) Manchmal wird mir gemeldet "Server Menü nicht erreichbar" bzw. "Verbindung bereits in Benutzung" (nur Sinngemäß)
b) Die (Remote) Kanalliste enthält nur die Überschriften aber nicht die Kanalnamen (nur '...')
c) Aufnahmen vom Server werden angezeigt lassen sich aber nicht Starten. Der Effekt ist dann das Live Bild auf dem Client bekommt Klötzchen und der Effekt von a) stellt sich ein.


Zu c:
Log auf Client:
Dec 27 14:09:43 (MLD) user.err vdr: [2007] ERROR: streamdev-client: Failed reading reply to 'ADDF 5100 2 255' from 192.168.2.4:2004: Connection reset by peer
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (0)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (1)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (2)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (3)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (4)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (5)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (6)
Dec 27 14:09:43 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (7)
Dec 27 14:09:44 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (8)
Dec 27 14:09:44 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (9)
Dec 27 14:09:44 (MLD) user.err vdr: [2048] cStreamDevice::GetTSPacket: GetChecked: NOTHING (10)
Dec 27 14:09:44 (MLD) user.err vdr: [2048] ERROR: streamdev-client: Couldn't connect to 192.168.2.4:2004: Connection refused
Dec 27 14:09:44 (MLD) user.err vdr: [2047] cStreamdevFilters::Action(): stream disconnected ?
Dec 27 14:09:44 (MLD) user.err vdr: [2047] ERROR: streamdev-client: Failed sending command 'ABRT 2' to 192.168.2.4:2004: Connection timed out
Dec 27 14:09:46 (MLD) user.err vdr: [2022] svdrpservice: invalid reply from 192.168.2.4: 'ertitel'
Dec 27 14:09:46 (MLD) user.err vdr: [2022] svdrpservice: lost connection to 192.168.2.4
Dec 27 14:09:46 (MLD) user.err vdr: [2022] EpgSync: LSTE error 0
Dec 27 14:09:46 (MLD) user.err vdr: [2022] svdrpservice: unable to send command to 192.168.2.4. Socket is closed
Dec 27 14:16:57 (MLD) user.err vdr: [softhddev] invalid PES video packet
Dec 27 14:16:57 (MLD) user.err vdr: [softhddev] 2 invalid PES video packet(s)
Dec 27 14:17:39 (MLD) user.err vdr: [2004] ERROR: Server Menü nicht verfügbar. Verbindung fehlgeschlagen.

Das Server Log (mit Default-Einstellungen) zeigt zu diesem Zeitpunkt gar nichts.

Die Aufnahmen auf dem Server liegen auf einem NFS Share auf dem Server. D.h. der Share wird sich zwischen OMV Host und MLD-Server (VirtualBox) geteilt.
Ist es vom Prinzip her richtig die Aufnahmen von VDR-Server zu VDR-Client über streamdev zu streamen? Oder habe ich das falsch verstanden.
Die andere Möglichkeit wäre ja dem Client (über den avahi-linker) den Share auch zugänglich zu machen. An dieser Stelle habe ich aber weitere Probleme, da der avahi-linker noch nicht will ...

Ralf

clausmuus:
Der Client muss auch den nfs share einbinden damit er die Aufnahmen wiedergeben kann. Aufnahmen werden nicht gestreamt.

baltic:
Hallo Ralf,

binde die Freigabe doch einfach mal über den entsprechenden Menüpunkt im Web-IF ein.

Gruß
Peter

Navigation

[0] Message Index

[#] Next page