[Wanninger]

@Claus

also ich habe in meiner Umgebung nur früher (zu prä MLD Zeiten) gelegentlich das RemoteOSD installiert,
wurde damit aber nie glücklich, da es immer wieder "Aussetzer" hatte, also nie wirklich zuverlässig war.
Mit dem RemoteTimers war es ähnlich - es hat nicht immer zuverlässig funktioniert.
Was beide Plugins zusammen gerne verursachten, waren zeitweise Blockaden des VDRs.

Ob die beiden Plugins noch weitere, mglw. wichtige Funktionen bereitstellen, derer ich mir nicht bewusst bin,
kann ich nicht sagen. Jedenfalls verwende ich sie nicht mehr und mir fehlt auch nichts.

@RaHe67

Über das restfulapi lässt sich das VDR OSD via http bedienen, so als hättest du z.B. nur das skincurses installiert.
Es reicht für die meisten "Arbeiten" aus. Wenn du auch die grafische Ausgabe brauchst, dann wäre xinelib...
und sxfe eine Alternative. Dazu brauchst du aber einen Linux PC oder eine LinuxVM, da das vdr-sxfe nur unter
Linux läuft.

---

Nachtrag:

Du kannst mal via tcpdump/tshark oder wireshark schauen, welche SRC/DST IPs und Ports an der hohen Netzlast
beteiligt sind... (sind aber nicht Bestandteil der MLD)

---

[RaHe67]

Über das restfulapi lässt sich das VDR OSD via http bedienen, so als hättest du z.B. nur das skincurses installiert.
Es reicht für die meisten "Arbeiten" aus. Wenn du auch die grafische Ausgabe brauchst, dann wäre xinelib...
und sxfe eine Alternative. Dazu brauchst du aber einen Linux PC oder eine LinuxVM, da das vdr-sxfe nur unter
Linux läuft.

So viel brauche ich gar nicht. Mit dem Live Plugin programmiere ich die Timer, um Einstellungen vorzunehmen komme ich über die Fernbedienungsseite auch auf das Server-OSD (vermutlich steckt da das restulapi hinter?). Ich denke damit kann ich schon alles was ich will und schaffe das sogar unter Windows.

Edit: Thread-Title mit Gelöst markiert

Ralf

[RaHe67]

Nachtrag:
Du kannst mal via tcpdump/tshark oder wireshark schauen, welche SRC/DST IPs und Ports an der hohen Netzlast
beteiligt sind... (sind aber nicht Bestandteil der MLD)

Unter Windows würde ich das hinbekommen. Unter Linux bin ich leider Anfänger.
Mein Aufbau 'hängt' an der einzigen Familienglotze - ist also ein Produktsystem an dem ich operiere. Von daher habe ich dort gerade eine Hemmschwelle :-)

Das nächste Projekt wird ein Spiel- und Backupsystem sein - das wird aber wie ich mich kenne etwas dauern.

Ralf

[clausmuus]

@Wanninger,
das svdrposd Plugin wird dann auf dem Server auch nicht mehr benötigt?

[Wanninger]

@Claus

Die folgenden Aussagen sind "AFAIK" und "AFAIR" !!

- remoteosd clientseitig, benötigt serverseitig das svdrposd - svdrposd hat sonst keine Verwendung
- epgsync, peer, femon, remoteosd und remotetimers, benötigen clientseitig das svdrpservice
- peer und femon müssen bei client/server Betrieb, serverseitig auch installiert sein
- epgsync und remotetimers benötigen serverseitig kein Hilfsplugin

Hattest Du nicht das "remotetimers" und "peer" Plugin auch schon im Angebot - bilde mir gerade
ein, beide schon mal gesehen zu haben. Wenn nicht, vllt. kannst du beide mal (wieder) in die Plugin
Liste mit aufnehmen.

---

[clausmuus]

remotetimers gibt es seit dem VDR 2.4 nicht mehr, da diese Funktionalität jetzt im VDR integriert ist. Ich glaube ich hatte das aber trotzdem mal hinzugefügt, um ein Zusammenspiel mit einem älteren Server zu ermöglichen.
peer hatten wir nie im Angebot.

[Wanninger]

Aha, o.k., das hatte ich noch nicht auf dem Schirm - dann vergiss getrost meinen zweiten Abschnitt aus Post #19

---

[RaHe67]

Ich komme nochmal auf diesen Thread zurück, da ich ganz oben auf ein Problem mit dem Avahi-linker Plugin gestossen war.
In der Zwischenzeit hatte ich das ja durch direkte NFS Mounts umgangen.

Habe heute einen guten Freund mit einer Funktionierenden MLD Server Client installation + aktiven Avahi Recordings Mount besucht. Und wir haben mal die eingebundenen Paket-Versionen verglichen. Dieser updated seine Pakete nicht mehr seit dem MLD Installations-Server Ausfall. Dabei ist uns folgendes aufgefallen:

Die Fehlermeldung bei meinen gescheiterten vdr-avahi-plugin Versuchen war, dass die Python Version nicht passte (aus der Erinnerung).

Funktionsfähig (altes Stable, vor dem Ausfall) <--> Fehler (neues Stable,aktuell)
python3   03.06.2003   <-->          python3   03.05.2003
python3-avahi   03.06.2000 <-->   python3-avahi   03.05.2000

Wir hatten die Vermutung, dass die Paketabhängigkeiten im Stable Zweig seit Eurem Hoster-Problem evtl. nicht mehr passen? Wenn ich mich (dunkel) richtig erinnere (ohne es nochmal ausprobiert zu haben) benötigt das avahi-linker-plugin von seahawk python 03.06? Ich finde die Referenzen gerade nicht mehr :-(

Gruß Ralf

[clausmuus]

Ja, das war bei der stable MLD so. Die unstable kommt wieder mit dem python 3.5 zurecht.