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

[RaHe67]

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

Das habe ich bereits gemacht, somit kann ich aus dem Client Aufnahmeverzeichnis problemlos auf die Aufnahmen zugreifen. Trotzdem Danke für den Hinweis.
Ich kopiere momentan alle Aufnahmen vom Client auf dem Server - das ist ein längerer Prozess ... Danach wollte ich nochmal die Unstimmigkeiten bezüglich des RemoteOSD ausprobieren und evtl. hier in einem Post sammeln wenn ich soweit bin - mühsam ernährt sich das Eichhörnchen.
Aber die Grundfunktionalität Aufnehmen und Wiedergeben ist jetzt bei mir dank Eurer Hilfe soweit schon mal gegeben - ich nähere mich dem Ziel an :-)

Merkwürdig fand ich nur, dass mir auf Server-Seite das Einbinden einer NFS-Freigabe als Datenverzeichnis (im Web-IF) extreme Mühe bereitet hat. Das ging erst, nachdem sowohl das Freigabeverzeichnis auf OMV als auch /data auf dem Virtuellen MLD Server leer war. D.h. die 'Recordings', 'TV' usw. Ordner musste ich löschen, damit das mounten ging.

Fehlermeldung wie hier:

Code: [Select]

ext4 filesystem found on /dev/sdb1
Mounting to /mnt/sdb1:
can not mount device sdb1
failed
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
mount: mounting /mnt/sdb1 on /data failed: No such device

Viele Grüße
Ralf

[clausmuus]

Das ist normal. Der Mount von fuse Filesystemen gehen nur in leere Verzeichnisse. Normalerweise ist der /data Ordner bei der MLD aber auch leer, das der fuse Mount ja von Anfang an besteht.

[RaHe67]

Normalerweise ist der /data Ordner bei der MLD aber auch leer, das der fuse Mount ja von Anfang an besteht.

Dann lag das Problem wohl darin, dass ich versucht habe, ein bestehendes Recordings Verzeichnis so einzubinden. Die Fehlermeldung ist ja eindeutig genug ...

Nochmal zu meinem Verständnis:
Die Verbindungsprobleme über RemoteOSD siehe oben bestehen bei mir immer noch. Sehe ich das richtig, dass ich mit der Verwendung von Streamdev zum Streamen des Live-Kanals, dem Einbinden der Aufnahmen über NFS Share von Client zu Server und dem Timer Setzen über das Live Plugin eigentlich alles abgedeckt ist? Andersherum gefragt brauche ich das RemoteOSD überhaupt bzw. setzt Ihr das zur Server-Steuerung ein? Wenn nicht könnte ich mir die Ursachenforschung sparen ...

Ralf

[clausmuus]

Grundsätzlich scheint alles korrekt zu sein. Wofür die einzelnen Plugins beim Client verwendet werden weiß ich leider nicht mehr. Aber die sind nicht grundlos mit dabei. Mit der Bildqualität haben die aber nichts zu tun

[rfehr]

Hi,
 das Live Plugin hat nichts mit client/server zu tun es ist nur ein WebFrontend ür den VDR,
um über einen Browser Timer zu setzen.

bei client/server Umgebungen ist wenn es von vdr/ zu vdr geht streamdev-server und stream-client das mittel.

Gruß
 Roland

[Wanninger]

Das mit dem RemoteOSD ist so ne Sache. Wirklich brauchen tust du es nicht.

Ich deinstalliere es auch immer, weil es für mich keinen Nutzen hat.

Dieses Plugin gibt es schon seit den Urzeiten des VDR und wurde früher benutzt um das OSD
eines sog. Headless Servers, am Client sichtbar und bedienbar machen zu können. Man konnte
damit z.B. Timer auf dem Server programmieren oder einfach nur Einstellungen am Server vornehmen.

Es gab dann auch noch ein remotetimers Plugin, dass das Timermenü am Client ersetzte und in
Wirklichkeit direkt auf dem Server programmierte. Man konnte damit aber auch Timer zwischen
den VDRs austauschen.

Die genannten Probleme mit dem remoteosd gab es früher auch schon und leider ist da auch
keine Besserung in Sicht, da der Entwickler dieser speziellen Client/Server Plugins, die Entwicklung
eingestellt hat.

Seitdem der VDR auch so gut über den Browser bedienbar ist, mache ich meine Server Einstellungen
hauptsächlich über das restfulapi, oder ich hole mit den Server Bildschirm komplett über xineliboutput
und vdr-sxfe auf meinen PC rüber. (Es wird dabei nur der Bildschirminhalt des Servers übertragen)

---

[clausmuus]

Wenn ich das jetzt richtig verstehe, sollten wir das remoteosd aus der Zusammenstellung der Clients entfernen, weil dies zeitweilig Probleme macht und keine erforderliche Funktionalität beisteuert?
Ich habe noch nie ein server-client System produktiv verwendet, kenne die Probleme somit also auch nicht aus eigener Erfahrung.

[RaHe67]

Mit der Bildqualität haben die aber nichts zu tun

So war das auch nicht gemeint  , es scheint nur so zu sein, dass sich bei Benutztung von RemoteOSD Netzwerkprobleme  einstellen, so dass das Live-Bild über mein Gigabit-LAN nicht mehr genug Bandbreite bekommt.

Die genannten Probleme mit dem remoteosd gab es früher auch schon und leider ist da auch
keine Besserung in Sicht, da der Entwickler dieser speziellen Client/Server Plugins, die Entwicklung
eingestellt hat.

Ja danke. Genau den Hinweis brauchte ich. Warum auch immer habe ich in den Foren dazu keine Kommentare gefunden. Scheint wohl nicht mehr viel in Benutzung zu sein.
Aktiviert hatte ich es, da ich langsam von meiner reinen Client Umgebung auf Client Server migriert habe. D.h. am Anfang sollten Client und Server erstmal unabhängig voneinander laufen - wobei der Client weiter lokal aufnimmt und der Server Testweise Aufnahmen erzeugt (und Remote Steuerung über das RemotOSD) - das war ein Schritt zu kurz.

... mache ich meine Server Einstellungen
hauptsächlich über das restfulapi ...

Nur damit ich es richtig verstehe: du steuerst Deinen Server über XML bzw. JSON TextStreams aus dem Browser? Ich dachte das wäre eher eine Programmierschnittstelle aber vermutlich kann man so Eigenschaften auch ganz gut verändern bzw. Kommandos absetzen. Ich schaue es mir bei Gelegenheit mal an.

Zuletzt noch einmal VIELEN LIEBEN DANK an alle die mir hier mitgeholfen haben. Ich denke ich bin so weit dass das System produktiv arbeitet und ich mich wieder die nächsten Tage etwas mehr um die Familie kümmern kann ... Die war schon etwas genervt ;-)

ALLEN EINEN GUTEN RUTSCH und ein frohes neues Jahr


Ralf

[RaHe67]

Wenn ich das jetzt richtig verstehe, sollten wir das remoteosd aus der Zusammenstellung der Clients entfernen, weil dies zeitweilig Probleme macht und keine erforderliche Funktionalität beisteuert?
Ich habe noch nie ein server-client System produktiv verwendet, kenne die Probleme somit also auch nicht aus eigener Erfahrung.

Zumindest mir hat es massive Probleme bereitet, und mich auch auf die falsche Fährte geführt - z.b. die Annahme ich könnte Aufnahmen darüber starten bzw. auf dem Client abspielen.

Ralf

[clausmuus]

Über das restfulapi Plugin wird im Webif das OSD bereitgestellt. So lässt sich der VDR (per OSD) über das Webif konfigurieren, bzw. bedienen.