[Marcus]

Wie reagiert denn der Server auf die vielen ankommenden Verbindungsversuche? Normal kann das Verhalten ja trotzdem nicht sein. Man sollte erwarten können, dass der erste Verbindungsversuch, der den Server erreicht, auch prompt beantwortet wird. Und wenn diese Antwort beim Client ankommt, wovon man ja ausgehen können sollte, da die Verbindung ja bereits in anderer Richtung funktioniert, sollte die Verbindung stehen.

BTW, ich beobachte dieses Verhalten schon lange (Jahre). Meine MLD 5.4 Raspberry's haben auch (sehr) oft keine SVDRP peering Verbindung zum Server. Trotz streamdev-client. Der Server ist keine MLD, sondern Debian 11 mit eTobi Paketen. Das Protokoll scheint sehr anfällig zu sein.

[franky]

@marcus
Wenn bei der MLD 6.5 auf dem Client (habe z.B. einen Wyse5070 der mit seinem 16GB eMMC als reiner Streamdev-Client konfiguriert ist) das streamdev-client Plugin installiert ist, wird die SVDRP Verbindung nach jedem VDR-Start sofort nach dem Start des Plugin aufgebaut.
Da baut dann streamdev erst die VTP Verbindung auf und sofort danach die SVDRP Verbindung.
Das funktioniert zu 100% nach jedem Systemstart und die Remote-Timer des Servers sind sofort sichtbar.

Das Problem gibt es bei der MLD 6.5 aktuell nur, wenn kein streamdev-client installiert ist und man am Client z.B. für den Empfang SatIP nutzt, wie das bei wayne der Fall ist, aber trotzdem lokal nicht aufnehmen möchte sondern nur zentral auf einem VDR-Server Aufnahme-Timer programmieren möchte.
In diesem Fall wird die SVDRP-Verbindung für die RemoteTimer nicht immer nach dem Systemstart aufgebaut und es braucht oft mehrere Anläufe bis die SVDRP-Verbindung steht.
Ob jetzt da der Server oder der Client das Problem hat eine Verbindung aufzubauen, kann ich in den Logs auch nicht feststellen.

KLS hat auf jeden Fall heute im VDR-Portal nach Anfrage von Claus einen neuen Patch vorgeschlagen.
Dieser soll die Häufigkeit der SVDR discover Anfragen des Client minimieren.

[clausmuus]

Es gibt einen neuen Patch von kls. Beim letzten wurde nicht alle 3 Sekunden ein Verbindungsversuch gemacht, sondern alle 3 ms bis die Verbindung steht. Das dürfte natürlich zu Problemen führen.
Der neue Patch macht sich einmal pro Minute bekannt, egal ob eine Verbindung besteht oder nicht.
Der Build für den x86'er läuft gerade. Bitte mal ab in 15 Minuten testen ob die neue Version besser geht. Ich erwarte dass die Verbindung nach ca. einer Minute steht. Eventuell ändert sich das Verhalten auch, wenn ebenfalls der Server aktualisiert wird.
Bitte auch bescheid geben, falls es wieder Probleme mit dem Update von Plugins gibt.

[franky]

@claus
Mit dem neuen Patch hat sich das Verhalten bei mir wieder verschlechtert.

Eigentlich ist es wieder so wie vor dem ersten Patch.
Manchmal wird die SVDRP sofort aufgebaut aber bei 4 von 5 Systemstarts kommt nach der ersten SVDRP Anfrage des Clients keine Verbindung zustande.
Der Client wiederholt diese discover Anfrage aber auch nicht mehr, auch nicht einmal pro Minute.
Ich habe bis zu 30min gewartet und da kam nichts mehr.
Erst nach einem VDR-Restart kommt dann die Verbindung zustande.

Nach dem ersten Patch hatte ich in den Logs wirklich nur alle 3 Sekunden diese Anfrage.
Wenn die auf 3 Millisekunden eingestellt war, müsste die Meldungen doch mehrmals pro Sekunde in den Logs erschienen sein.
Das waren dann schon mal 40 Meldungen mit SVDRP-Anfragen in 2 Minuten, aber dann hat die SVDRP-Verbindung wenigstens funktioniert.

Mal schauen, was wayne berichtet.

[wayne]

Ich kann das bestätigen.
Bei mir sieht es genauso aus wie bei franky.
Es hat sich wieder verschlechtert...

[clausmuus]

Ich glaube kls hat sich da mit dem Rückgabewert einer Funktion vertan. Ich habe den Patch daher noch mal leicht geändert. Ihr könnt das in 10 Minuten noch mal testen.

[franky]

Ich habe mir jetzt für die Tests ein weiteres System, einen NUC8i3 mit SatIP konfiguriert, der den Systemen von wayne besser entspricht.
Mit dem neuen patch hatte ich bei diesem System bei 3 von 5 Neustarts bei der ersten SVDRP Anfrage beim Server eine Verbindung.
Bei den 2 Mal, wo das aber gescheitert ist, wurde die Anfrage jetzt nach einer Minute wiederholt.
Die Verbindung kam dann aber doch erst nach 4 oder 5 Wiederholungen zustande, was bei einem 1 Minuten Intervall doch bis zu 5min dauert.
Jetzt wird aber auch im Minuten Takt weiter gesendet, auch wenn die SVDRP-Verbindung steht.
Eine etwas kürzerer Intervall von 20 oder 30s wäre vermutlich doch besser, wobei dann aber das neue Verhalten mit dauerndem Senden der Anfragen evtl. stört.

[wayne]

Guten Morgen,

jetzt wurde gerade bei 8 Mal booten 8 Mal sofort verbunden!

Was ich gemacht habe:

1. Die neuen Updates installiert
2. Das vdr-plugin-svdrpservice auf dem Server deinstalliert, weil ein alter Kommentar von kls war:
https://www.vdr-portal.de/forum/thread/136579-timer-auf-dem-server-werden-nicht-angezeigt-keine-verbindung-mit-svdrp/?postID=1377004#post1377004

Funktioniert bei mir einwandfrei.
Allerdings habe ich kein "svdrpservice" installiert (was auch immer das macht).
Lass das mal weg.

Habt Ihr das vdr-plugin-svdrpservice installiert? Kann es ein, dass sich da was beißt?

[franky]

@wayne
Ich hatte auf meinem Server das Plugin svdrpservice installiert, da ich auch markad installiert habe.
Ich habe mal zum Test auch auf dem Server svdrpservice deinstalliert, wobei dann auch markad deinstalliert wurde.
Wenn ich markad wieder installiere, wird auch svdrpservice wieder installiert.
Auf den beiden Test-Clients hatte ich weder markad (macht da auch wenig Sinn) noch svdrpservice installiert.

Danach hatten auch meine beiden Test-Clients bei jedem Systemstart sofort eine SVDRP-Verbindung mit dem Server aufgebaut.
Da scheint also tatsächlich das svdrpservice Plugin auf dem Server den SVDRP Verbindungsaufbau zu stören.

Wayne, wenn du bei deinem Server auf das svdrpservice Plugin verzichten kannst, da du sonst kein Plugin installiert hast, das davon abhängt, ist das für dich ja die beste Lösung.

Ich möchte auf meinem Server eigentlich nicht auf markad verzichten.
Das ist bei mir aber auch kein Problem, da ich ja bei meinen produktiven Streaming-Clients immer das streamdev-client Plugin verwende, wo das Problem sowieso nicht auftritt.

Ich habe auch auf dem Server die aktuelle VDR-Version laufen, wobei ich es etwas irritierend finde, dass außer den Clients jetzt auch der Server dauerhaft einmal pro Minute ein SVDRP:discovery sendet.
Aber wenn es nicht stört, ist das ja OK.

[clausmuus]

Habt Ihr auf dem Client auch Plugins wie epg-sync installiert? Das würde erklären warum die Verbindung so lange braucht. Dann würde svdrpservice so lange die svdrp Schnittstelle blockieren, bis die epg Daten Synchronisiert sind.

[wayne]

@claus:
Habe epgsync nicht installiert.

@franky:
Hatte und hätte schon gerne markad installiert.

Mal für mich zum Verständnis:
Was macht das vdr-plugin-svdrpservice?
Hat der VDR nicht die svdrp-Schnittstelle von Hause aus "im Bauch"?
Wenn ja, benötigt dann überhaupt markad das vdr-plugin-svdrpservice?

[franky]

@claus
Ich habe epg-sync nicht installiert.
Das ist ja eines der Plugins, das laut der Entwickler Homepage wirklich ein installiertes svdrpservice Plugin benötigt.
https://vdr.schmirler.de/

@wayne
Mich wundert die Abhängigkeit von markad und svdrpservice auch.
In den Beschreibungen zu markad kann ich keine Hinweise finden, dass markad das svdrpservice Plugin benötigt.

[clausmuus]

Das mit der markad Abhängigkeit prüfe ich gerade.

Macht es eigentlich auch Probleme, wenn svdrpservice auf dem Client installiert ist?

[franky]

@claus
Ich habe das mal mit dem svdrpservice Plugin auf dem Client mit meinem NUC getestet.
Auch am Client stört das Plugin, aber deutlich weniger, als am Server.
Bei 1 von 5 Systemstarts hat die Verbindung nicht bei der ersten SVDRP Anfrage funktioniert.
Da der Client jetzt aber jede Minute ein Anfrage sendet, waren dann nach einer Minute die RemoteTimer sichtbar.

[clausmuus]

Auch auf dem Server wird das discover immer wiederholt, weil auch der Server mal eine Verbindung zu einem Client verlieren könnte. Und nur so ist sichergestellt, dass dieser alle Clients im Netz kennt.
Das svdrpservice Plugin vereinfacht die Programmierung, wenn eine Plugin eine svdrp Verbindung benötigt. Außerdem können sich so mehrere Plugins eine Verbindung teilen. Das Plugin blockiert jedoch die svdrp Schnittstelle (wenn es aktiv verwendet wird), da es diese Schnittstelle verwendet.