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 (
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