Perler brauch mal C Support ;)

Hallo Freunde,

ich sitze zur Zeit an einem vertrackten Problem und komme mit meinen Kenntnissen einfach nicht weiter. Ich habe XXV einem SOAP-Interface gegönnt, damit kann ich mit einem Client Programm auf den Funktionsumfang von XXV sicher zugreifen.

Jetzt sitze ich an einem Client der im Grunde das altbekannte GraphTFT ablösen soll. Dieser ist auch schon sehr weit fortgeschritten. Dieses Tool stellt zur Zeit nur einen Statusscreen per SDL dar, das anzeigt was gerade im vdr läuft. Ich brauche aber einen Rückkanall damit der Client erkennt wann auf einen anderen Sender umgeschaltet wurde usw.. Natürlich hätte ich jetzt XXV im Intervall von 5 Sekunden nerven können, aber das ist uneffizient. Zumal ja xxv auch (wieder mal) den SVDRP-Server nerven muss um herauszufinden ob sich der Channel geändert hat. Da XXV schon von Hause aus SVDRP sehr oft nutzt (Timer, Aufnahmen aktualisieren ...) ist das absolut keine Option. Zumal ja bei offenen SVDRP die anderen Programme warten müssen, die ebenfalls an SVDRP zugreifen wollen.

Cool wäre es wenn ein Plugin existieren würde, das per UDP-Broadcast bestimmte Events rausschreien würde (ChannelChange, StartRecord, StopRecord, ... ). Vielleicht könnte man sogar das SVDRP Interface per UDP emulieren (Client:UDP(CHAN) -> Vdr:UDP('2 ZDF')->Client:UDP), das aber nur lesende Operationen unterstützen würde.

Für ein C-Progger sicher ein einfaches Vorhaben, aber mir leider zu hoch.

Please Help
Euer xpix

Kann sich da nich ma eener von den C'lern erbarmen? Wär echt nett

Zitat

Original von Hulk
Hi,

versuche es doch mal mit dem Kvdrmon-plugin.

http://vdr-statusleds.sourceforge.net/kvdrmon/
http://www.vdr-wiki.de/wiki/index.php/Kvdrmon-plugin

dürfte aber nicht alle deine Probleme lösen, sprich es muss weiterhin gepollt werden.
Allerdings ist der SVDRP Port frei.

Alles anzeigen

Auf jeden Fall erstmal ein guter Tipp um so ein Client/Server auf pluginBasis nach zu vollziehen.

Zitat

BTW: Warum UDP Vorteile bringen sollte erschliesst sich mir nicht, da keine großen Datenmengen gesendet werden müssen. TCP dürfte sinnvoll sein, da keine eigene Fehlerkorrektur implementiert werden muss, da dies der TCP/IP Stack übernimmt.

Andreas

Auf den ersten Blick schon, aber bei einem TCPConnect muss man auf die Antwort warten. Das kann u.U. schon mal länger dauern und der Client ist verdammt zu warten. Fehlerkorrektur ist IMHO nicht nötig da ein verlorenes Packet in einem LAN höchstens alle 10000 Pakete vorkommt.

Erstmal Sorry für meine späte Antwort, Arbeit geht vor

Zitat

UDP packete in die Welt zu schreien ist sehr simple. Sinnvolle kommunikation damit hinzubekommen aber schwer.

Da hast du natürlich Recht. Es muss ja nicht unbedingt Broadcast sein, auch Unicast würde es tun.

Zitat

Ich kann den Aufwand ein Plugin zu schreiben das diese "Events" mitbekomment nicht abschätzen. Wenn es noch nötig ist kann, ich es mir ja mal anschauen. Schreib doch mal was du genau gebroadcastet haben willst.

Na das wichtigste steht ja wirklich schon in dem Beispiel des 'status' Plugins, das Klaus ja als Beispiel in seinem vdr Paket mit drin hat. Diese Informationen würden eigentlich schon reichen. Ich habe mir auch mal das, von Hulk empfohlene, Plugin kvdrmon angeschaut das im grunde einen eigenen SVDRP aufbaut:

http://vdr-statusleds.sourceforge.net/kvdrmon/
http://www.vdr-wiki.de/wiki/index.php/Kvdrmon-plugin

Das würde vollkommen reichen, nur ebend als UDP und nicht Telnet. Wäre der Umbau sehr kompliziert?

Zitat

Original von hotzenplotz5
xpix bist du schon weiter ?
will nicht drängeln, soll eher sowas wie "gib nicht auf" frage von mir sein
verstanden

Danke ... also die Lösung hab ich schon in den o.g. plugin gefunden. Dies ist eine klassische TCP-SVDRP Lösung. Ich denke mal mit dem Konstrukt und dem Beispiel des status plugins kann ich super arbeiten.

Zur Zeit arbeite ich aber an der Beta für XXV damit wir rechtzeitig zur stable 1.40 rauskommen können. Danach (in der Sommerpause) bin ich bei einem C Kurs in der Volkshochschule und arbeite dann mit Nachdruck an dem XXV-Client. Also keine Bange .... ich bleib dran.