SVDRP "Proxy"? Hat schonmal wer was in der Richtung gemacht?

Hi!

Also von der Limitierung merkt man doch eigentlich eh nicht wirklich was oder?
Z.B. habe ich XXV und epgsearch am Laufen und ich hätte noch keine Probleme gehabt. Auch nicht wenn ich dann zusätzlich noch einen SVDRP-Befehl auf der Konsole abgesetzt habe. Früher hatte ich öfters Probleme damit, aber mit den aktuellen Versionen von VDR nicht mehr.

Gruß,
Brougs78

Schöner wäre SVDRP selbst als eigenen Thread zu implementieren (damit entfällt die Wartezeit von bis zu 1 Sekunde bis VDR sich um SVDRP kümmert) und dann natürlich jede Verbindung als eigenen Thread. Dann könnte z.B. auch das streamdev-plugin über SVDRP arbeiten. Ein Teil des streamdev-servers ist momentan eine Nachimplementierung von SVDRP, nur eben mit Threads.

Zitat

Original von schmirl
Ein Teil des streamdev-servers ist momentan eine Nachimplementierung von SVDRP, nur eben mit Threads.

Nein, mit einem Thread für Server und Clients (zumindest bis hin zur eigentlichen Datenübertragung)

Zitat

Original von s_herzog
IMHO ist es doch auch so, dass für die Dauer des Zugriffs per SVDRP der VDR auch für die Fernbedienung blockiert, oder?

Nicht für die Gesamtdauer des Zugriffs, aber schon für die Dauer der Abarbeitung eines einzelnen SVDRP-Befehls. Bei LSTE ist das aber auch schon ganz schän lange

Viele der nötigen Methoden sind inzwischen irgendwie thread-safe herausgeführt, aber einige sind immernoch nicht von einem Thread aus aufrufbar... Für erstere gibts dann fertige Locking- (Kanäle, EPG, Aufnahmeliste) oder Queueingmechanismen (OSD-Messages) für die Plugin-API.

Hmm... vielleicht eine Multithread Lösung, d.h. pro Client wird wie üblich ein Thread gespawned (<- wie man das wohl auf deutsch ausdrückt).
Für Resourcen für die kein Locking existiert müsste man in SVDRP ein Locking einbauen. Alle Anfragen werden dann solange gequeued, bis die jeweilige Resource wieder entsperrt ist.

Hallo,

mein Antrieb in dieser Richtung was zu tun war nicht der Bedarf von mehreren Maschinen gleichzeitig den VDR bedienen zu wollen, sondern einfach der Wunsch nach schnelleren Antwortzeiten.

Der Proxy läuft bei mir auf meinem kleinen VDR unter LinVDR und funzt zu meiner Zufriedenheit

Vielleicht paßt er ja auch bei Euch?

Das größte Problem sind die Operationen, die etwas editieren oder löschen. Da wird ja die fortlaufende Nummer zur Identifizierung verwendet, und diese Nummer kann sich von Verbindung zu Verbindung ändern. Insbesondere ist Chaos vorprogrammiert, wenn zwei SVDRP-Kunden gleichzeitig Timer verändern oder ähnliches. Oder eine Verbindung bearbeitet etwas, was kurz zuvor von einer anderen Verbindung gelöscht wurde.

Eine saubere Lösung müsste am SVDRP-Protokoll ansetzen, und entsprechendes locking implementieren. Sehr aufwändig.

Gruß,

Udo

In dem Punkt kann ich Dir nur zustimmen!
Ohne Unterstützung des VDR ist alles weitere locking o.ä. nur vertane Zeit.

Deshalb unterstützt dieser Proxy nur RO-Operation direkt und leitet alle anderen Aktionen an den VDR weiter.

Für meinen Bedarf reicht diese Funktionalität, da das Antwort-Zeitverhalten (rein subjektiv) deutlich verbessert wurde

Die Verbindung zum VDR ist atomar, d.h. wenn zufällig zwei gleichzeitig was vom VDR wollen, bekommt der erste die Verbindung und der zweite eine Fehlermeldung.

Da kann man jetzt drüber diskutieren, was besser is:
warten ohne Rückmeldung, oder ne Fehlermeldung zu bekommen und es aktiv neu zu versuchen ...

P.S. by the way:
So aufwändig muss das nicht sein.
Wenn man einen Zeitstempel der letzten Änderung, oder einen Änderungszähler mitführt und der VDR eine Änderung nur akzeptiert, wenn der Zeitpunkt, bzw. der Zähler paßt, müßte der Aufwand eigentlich überschaubar bleiben (und auf komplexes Locking könnte verzichtet werden).
Natürlich muss das Format der Schnittstelle dann angepaßt werden.