DVBServer Interface

[Okin]

Ich bin auf der suche nach einer Interface Beschreibung des DVBServers.

Habe bisher noch nichts darüber gefunden. Was ich bis jetzt glaube verstanden zu haben ist das der Server zwei Ports zur verfügung stellt. Über den einen wird gestreamt und über den anderen wird der Server gesteuert. Wenn das so ist sollte es recht einfach sein einen Client für das Steuern des Servers zu Programierern.

Ich möchte mir ansehen wieviel aufwand es wäre einen native Clienet für XBMC zu programieren.

Spezielle bitte an Lars gibt es irgendeine Beschreibung wie das Interface funktioniert?

[Tjod]

Für die Kommunikation mit dem Server gibt es keine Dokumentation. Und es kann auch gut sein das es da in den nächsten Versionen größere umbauten geben wird.

http://www.DVBViewer.info/forum/index.php?...st&p=193137

 

So wie ich das verstanden habe macht DVBSBridge auch was in die Richtung.

Das setzt aber auf die API des DVBViewer auf und nicht auf den DVBServer. Eventuell ist in dem Zusammenhang auch das Topic für dich interessant:

http://www.DVBViewer.info/forum/index.php?...c=26352&hl=

[Lars_MQ]

Das interface funktioniert im moment noch recht simpel (in der einfachen ausprägung mit einem client pro IP, das dürfte hier zutreffen).

 

Über den commandport sendet man an den Server ein

"SETTUNER " + die entsprechende tunerstruktur in der form:

  result :=
Format('%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9'%d'#9,
[ord(Tuner.TunerType),
Tuner.Frequency,
  Tuner.SymbolRate,
  Tuner.LOF,
  Tuner.Tone,
  Tuner.Polarity,
  Tuner.Diseqc,
  Tuner.FEC,
  Tuner.AudioPID,
  Tuner.VideoPID,
  Tuner.PMT,
  Tuner.SID,
  Tuner.SatModulation,
  ord(IsDVB_S2(Tuner)),
  Tuner.DiSEqCValue,
  Tuner.Flags,
  ord(Tuner.Group)]);

also durch #9 (tab) getrennte werte. abgeschlossen wird das ganze mit einem crlf (#10#13).

Das wird durch eine "OK." oder "FAILED." klartext message bestätigt

Der Streamclientport empfängt dann den TS stream.

 

Insgesamt ist das für die meisten applikationen nicht sehr sinnvoll, da sie genaue kenntnisse über de tunerstrukturen haben müssen (und sogar eigene scans durchführen müssen). Deshalb ist die schnittstelle aus gutem grund ncht so öffentlich (mal abgesehen davon, das sich das protokoll ohne ankündigung ändern kann und demnächst wird).

 

Vielleicht wäre es sinnvoller auf die erweiterungen des dvb recording service zu setzen. Dort erarbeite ich grade ein http/xml (soap für arme ) lösung, die eine abfrage der zugrundeliegenden daten (sender/timer/epg/aufnahmen) erleichtern sollte und auch ein live/filestreaming bietet. Die entsprechende beta (noch ohne xml) schiebe ich wahrscheinlich morgen raus.

Vorschläge für das xml format können noch berücksichtigt werden

[Okin]

Das der Client einen Scann zum anzeigen der Kanäle benötigt habe ich Übersehen, das ist natürlich unschön.

Eigentlich war die Idee auf eine direkte Komponente des DVB Viewers oder Servers zuzugreifen ohne zusätzlich einen Server starten zu müssen, aber ein Service ist immerhin besser als ein Server

 

Wie weit soll den das pseudo Soap gehen?

Abfrage der daten ist gut stream auch aber wie sieht es mit Steuerkommandos aus. An die EPG daten müsste ich auch rannkommen damit es schön wird.

 

Hat der service jetzt schon einen einen Port zur kommunikation und was läuft da drüber?

 

Was ist den schon in xml vorgesehen? Gibt's da schon was an infos?

[Lars_MQ]

ja hat er, port 80 und es läuft der webserver darüber (siehe die neue beta mit LiveTV directstreaming)

 

Wie gesagt xml wird noch nicht ausgegeben, ist aber eher eine der leichteren übungen. man müsste nur einen schlauen aufbau für die drei grossen bereiche (epg/timer/channels) finden (die schwere übung ). Die commandstruktur (also das client seitige anstossen dverser aktonen) lässt sich jetzt schon realisieren über simple html gets.

 

Timer sind nicht so schwierig, epg muss man clientseitig so aufbauen, das nur das benötigte angefragt wird, weil 17 MB an reinen epg daten (mit XML kommen vielleicht nochmal 5 MB dazu) müssen nicht in einem schwung übertragen werden

Die channels sind die grösste herausforderung. Dort muss auf jedenfall jeglicher bezug auf frequenzen und PIDs gekickt werden und mit einfachen strukturen und beschränkten listen gearbeitet werden (eine art von vordefinierten favoriten listen). Mit den echten tunerstrukturen kommt man dann nicht in berührung. Also nix für feedhunter.

[Okin]

Wie sieht denn das interface zwischen dem dvb recording service und DVBViewer aus.

Ich denke um eine XML komnmandostrucktur zu definieren sollte man erst mal sehen wie das andere ende aussieht. Damit ist es dan möglich das dvb recording service die ckommandos mehr oder weniger tunnelt.

 

Zu den den channels.

Am sinnvollsten wäre es meiner meinung nach die die im DVBViewer angelegten favorieten zu nutzen dazu müsste zunächst die Favorietendaten von der client seite abgefragt werden und auf clientseite eine liste (Baum) aufgebaut werden. Dann braucht man noch das kommando um direkt auf eine bestimmte favorieten nummer zu springen. Was dann noch fehlt ist die verbindung zu den epg daten damit der client diese auch der internen Senderliste zuordnen kann. Für die Liste wären natürlich auch die sender icons interressant.

 

Der stream der derzeit geliefert wird hat nur einen audio stream kann man das irgendwo einstellen das alle streams gesendet werden?

[Lars_MQ]

So wie die favoriten beim DVBViewer organisiert sind, werde ich sie mit sicherheit nicht ohne weitreichende änderungen übernehmen. Mir schwebt da es sinnvolleres vor als das jetzige. Etwas strikteres. Also kein wir raten mal welcher kanal das ist, sondern eine 1:1 Beziehung, die der Nutzer zu verantworten hat und nicht die software.

 

Die interoperatibilität mit dem DVBViewer, so wie sie jetzt ist, wird eh in den nächten versionen immer weiter gelöst, bis der DVBViewer schliesslich auch "nur" als client für den service agiert oder eigenständig und als konkurent um die resourcen.

[Okin]

Ich habe jetzt erst verstanden das der "Recoding service" quasi ein kompletten Server service darstellt.

 

So gesehen ist es natürlich ein idealer port.

 

Was für gets kann ich denn schon verwenden um an daten wie die sender namen zu bekommen. Gibt es da etwas direktes oder muss ich mir das aus der antwort page des Webinterfaces herausfrimeln?

Wie sieht es zum umschalten der Sender aus? soweit ich gesehen habe läuft alles über get oder gibt es auch was zu posten.

 

Wovon ich gar keine ahnung habe ist. wie liegen die epg daten vor?

 

by the way, ist es möglich in den viedeostream alle audiostreams einzubinden? dann könnte der client die auswahl übernehmen.

[Lars_MQ]

Wie sieht es zum umschalten der Sender aus? soweit ich gesehen habe läuft alles über get oder gibt es auch was zu posten.

Senderumschaltungen werden über get laufen, da das sehr viel einfacher ist und die datenmenge mit sicherheit die erlaubte länge überschreiten wird.

 

Wovon ich gar keine ahnung habe ist. wie liegen die epg daten vor?

Daran arbeten @delphi vom auto XMLTV import plugin und ich gerade. Es wird dort eine get http anfrage geben, die dann eine XML antwort liefert. Um EPG in den service zu senden wird mit POST gearbeitet.

 

by the way, ist es möglich in den viedeostream alle audiostreams einzubinden? dann könnte der client die auswahl übernehmen.

Wenn Du die direkte methode wählst (quasi ein eingebautes netstreaming plugin) dann wird das automatisch gemacht.

 

Im moment ist der service die hauptbaustelle und es gibt grosse umbrüche und erweiterungen. Ich werde die entsprechenden schnittstellen/ definitionen sobald wie möglich dafür liefern. Sicher ist, das ganze wird sich als (einfacher) webservice präsentieren. Das sollte sich aus den meisten sprachen (oder gar mit einem webbrowser only) relativ leicht ansteuern lassen...