http://satellite-board.de

@all

Unterschiedliche Editoren gibt's für verschiedene Hardware, selbst eines einzelnen Herstellers, z.B. Humax.

Unterschiedliche Settings gibt's für die verschiedenen Editoren.

Unterschiedliche Import-/Export-Schnittstellen gibt's für verschiedene Editoren und verschiedene Settings

Mancher Programmierer pflegt mehrere Editoren.

Mancher Sat_Fan pflegt mehrere Settings.

Mancher DXer sucht häufig neue Programme und möchte die 1 2 3 Ergebnisse seines Hobbies gerne mitteilen. An andere User, an Settingspfleger und Editorprogrammierer.

Mancher User hat mehrere Receiver mit mehreren Editoren und mehreren Settings, aber nur eine 1,2 GB-Platte in seinem MM-Zentrum installiert.

Und Jeder liest, lädt down, tippt ab oder kennt CtrlC und CtrlV.

Aber jeder aufgeschaltete Service hat (solange keine Änderungen seitens des Providers durchgeführt werden) immer die gleichen Kenngrößen.

Warum nicht eine "Visitenkarte" des Programms (des Transponders, des Providers, des Satelliten) definieren, das Ganze in ein leicht zu handhabendes, flexibles und zukunftsorientiertes Format packen und dann nur noch eine einzige bidirektionale Schnittstelle in allen Editoren und (vielleicht sogar) eine einzige zentrale Datenbank für diese Parameter (like CDDB und die CD-Player-Soft)

Wenn ich Editoren programmieren würde (zu alt), oder Settings pflegen würde (zu faul) würde ich XML in Betracht ziehen. Und wenn dann noch ein paar andere mitmachen, voila!

denkt mal
Janus

Infos: http://msdn.microsoft.com/xml/general/


[Dieser Beitrag wurde von Janus am 10. Januar 2001 um 13:08 Uhr editiert.]

Klingt gut,
den jeweiligen Konvertern (xml2humax5600) müssten dann nur noch mappings beigebracht werden, was sie wie verwenden, ändern etc - flexibler als statisch im Konverter selbst.

Ist sogar noch viel besser!

Konverter, Mapping und andere Austausch-Krücken sind völlig überflüssig.
XML als Beschreibungsformat ist, ähnlich wie HTML, strukturiert und unterliegt Vorgaben, die zur Zeit beim W3C definiert werden, sodaß auf die damit formulierten Daten über ein einfaches Objektmodell direkt zugegriffen werden kann.

Die mit Hilfe von XML beschriebenen Datenbestände können schematisch (über DTD oder xml-data) festgelegt werden (Hierarchie, Reihenfolge, Eigenschaften usw.)

Der Datenbestand kann daher mit zugehörigem Sprachvorrat (XSL) direkt beim Parsing wie gewünscht umstrukturiert werden. Heute aktuelle Browser haben einen solchen Parser in allgemeiner Form sogar schon integriert.

Es wäre daher eigentlich nur notwendig, das schematische DatenGerüst allgemeingültig und umfassend zu definieren. Mal ganz einfach gesagt

Bye
Janus

@Janus
wie hast du dir das vorgestellt - mal für einen Leihen. Die Boxen nehmen ja je nur ihr eigenes Format an, dies wehre dann eine Art Export/Import Format das dann von jedem Editor implementiert werden muß? Die Datenstrucktur ist teilweise sehr unterschiedlich. Z.B. ich exportiere von IQG.1 nach Matrix dann zu Technisat dann fehlen mir hier die PID, dann wieder zu IQG.1 und weg sind alle Bouquets und alle Providerkennungen.
Was meist du dazu?
cu oli

Endlich mal was Neues.

@oli

Grundsätzlich wird der Transfer zwischen Receiver und Editor so bleiben müssen wie er ist, nämlich hardware-abhängig.
(jede Hardware hat einen entsprechend angepassten Editor)

Der Vorteil der Verwendung von XML liegt im Bereich außerhalb der jeweiligen Hardware, im Austausch zwischen verschiedenen Editoren (die natürlich mit diesem XML richtig umgehen müssen, also: eine!! XML-Schnittstelle in jedem Editor), in der Information zwischen verschiedenen Usern, in der Verwaltung eines gemeinsamen Datenpools, der von allen Editoren und Usern auf die gleiche Art und Weise genutzt werden kann.


Einfaches Beispiel

Im hardwareabhängigen Humax-Format (wird dann noch verschlüsselt und gepackt) sieht das etwa so aus:

[TS]
0 0 11836 27500 0 2 1 1101
[PROVIDER]
ARD
[SERVICE]
V 28106 0 101 102 101 0 FALSE FALSE FALSE 0 0 eins
V 28109 0 401 402 401 0 FALSE FALSE FALSE 0 0 arte

Kurz und knapp, aber halt eben nur für bestimmte Humax-Receiver


Die gleichen Daten als XML-Datei:

<Transponder index='0'>
<AntennaIndex>0</AntennaIndex>
<NetworkIndex>0</NetworkIndex>
<Frequency>11836</Frequency>
<SymbolRate>27500</SymbolRate>
<Polar>horizontal</Polar>
<FEC>2/3</FEC>
<OrgNetworkId>1</OrgNetworkId>
<TSId>1101</TSId>
<Provider index='0'>
<Name>ARD</Name>
<Service index='0'>
<VideoMode>V</VideoMode>
<ServiceID>28106</ServiceID>
<PMTPID>0</PMTPID>
<VIDEOPID>101</VIDEOPID>
<AUDIOPID>102</AUDIOPID>
<PCRPID>101</PCRPID>
<ServiceKind>0</ServiceKind>
<Lock>False</Lock>
<Skip>False</Skip>
<Scramble>False</Scramble>
<TSIndex>0</TSIndex>
<ProviderIndex>0</ProviderIndex>
<ServiceName>Das Erste</ServiceName>
</Service>
<Service index='8'>
<VideoMode>V</VideoMode>
<ServiceID>28109</ServiceID>
<PMTPID>0</PMTPID>
<VIDEOPID>401</VIDEOPID>
<AUDIOPID>402</AUDIOPID>
<PCRPID>401</PCRPID>
<ServiceKind>0</ServiceKind>
<Lock>False</Lock>
<Skip>False</Skip>
<Scramble>False</Scramble>
<TSIndex>0</TSIndex>
<ProviderIndex>0</ProviderIndex>
<ServiceName>arte</ServiceName>
</Service>
</Provider>
</Transponder>


Einen geeigneten Browser vorausgesetzt (IE ab 5.0), sollte man nun bereits die Arbeit des eingebauten Parsers sehen, der in der Datenstruktur Plus- und/oder Minuszeichen eingefügt hat, etwa wie bei Verzeichnissen im Explorer. Ebenfalls sollten die <Tags> und die Dateninhalte farblich unterschieden sein. (Geht das hier im "Schwarzen Board"? Eventuell den ganzen Block kopieren, als Textfile mit Endung .XML speichern und im IE wieder einlesen)

Um diese Datendarstellung zu formatieren, zu bearbeiten und umzustrukturieren, gibt es jede Menge Tools (meist umsonst).

Darüberhinaus läßt sich mit modernen Programmiersprachen über das Objektmodell die Struktur ganz leicht einlesen, ausgeben und bearbeiten.

Humax-Editoren können nun diese Daten einlesen, in das humaxinterne Format umwandeln und zum Receiver schicken.
Oder Galaxis-Editoren lesen den Receiver nach einem "produktiven" Suchlauf aus und exportieren die neuen Sender in diesem Format an Matrix- und Technisat-Editoren. Oder an SatcoDX oder hier ins Board oder ...

Deinem Posting nach zu urteilen, bist Du mit den vielen Receivern schon ein wirklich geeigneter Kunde für XML-basierten Datenbestand.

Uups, ich hoffe, das war jetzt nicht zu lang oder zu viel oder zu hoch, aber es ist ja Wochenende.

@Derrick
Danke für die Anfeuerung

CU, vielleicht im Chat
Janus


Nachtrag: Schade, Darstellung kommt hier im Board nicht rüber, bleibt der Trick mit dem Kopieren

Tut mir leid,
Janus



[Dieser Beitrag wurde von Janus am 12. Januar 2001 um 18:24 Uhr editiert.]

Hm, schon ein wenig lang
Ich bin schon der Meinung das ein einheitliches Format her muß. Nur es gibt herstellerspezifische Besonderheiten die bei der Definition beachtet werden sollten. Um z.B. bei den PIDs zu bleiben es gibt Boxen die benutzen keine PID. Sie tauchen gar nicht in den Settings auf, exportiert man dies in ein "Universalformat"
steht bei allen PIDs eine "0" und keine andere Box kann damit was anfangen. Andersherum wenn eine Box ausschließlich mit PIDs arbeitet können wieder die anderen nichts damit anfangen usw. Ich bin mir nicht mal so sicher warum schon wieder was vom Microschuft sein muß. Ein einfaches Textformat oder csv würde vollkommen reichen. Entweder man baut da alle nur möglichen Daten ein oder man beschränkt sich auf Grundinformationen die wirklich immer gleich sind.
cu oli

@Oli

habe leider außer einer Volksbox und einer dBoxI (jeweils testhalber übers Wochenende vor ca. anderthalb Jahren) keine weiteren Receiver neben meinem 5400er gesehen. Ich bin also sicher nicht der geeignete Ansprechpartner für Strukturfestlegung von solchen Daten.
(Wie holen die Receiver ohne PIDs die Daten aus dem Stream?)

Es gibt zur Zeit viele Leute in der Software-Entwicklerszene, die sich über die Ablösung von CSV und anderen, weit ausgefuchsteren Datentransfer-Lösungen durch diesen XML-Ansatz von ganzem Herzen freuen. Weil wohl, so habe ich es jedenfalls verstanden, unter XML die Daten <u>und</u> ihre Struktur gemeinsam dargestellt werden. Niemand braucht damit letztendlich eine Dauer-Kommission zur Festlegung von Strukturdefinitionen.

Ich bin mit nicht sicher, ob XML von Golden Gates ist, aber eins muß man ihm auf jeden Fall lassen: Er hat ein Gespür für Dinge, die sich durchsetzen [lassen].

Ich bin auch kein XML-Guru, sondern mehr ein Anwender mit Blick auf die praktische Lösung eines Problems, allerdings mit relativ vielen EDV-Literatur-Abos. (LowLevel-Experte sozusagen)

Entscheidend für ein einheitliches Format sind aller Voraussicht nach nur die Programmierer von Editor-Soft. Wenn deren Kosten/Nutzen-Vergleich stimmig ist, dann ja!

Aber das könnten wir ja hier ausloten!

Gruß
Janus

Im allgemeinen werten die Boxen die SID aus. Die SID ist eine Adresse innerhalb des Streams wo wichtige PIDs abgelegt sind, so können mehrere APID dort liegen die dann die Box so nur einem Programmplatz zuordnen kann. So bemerkt man mit so einer Box nicht wenn sich PIDs ändern... Einige SCPC senden keine SIDs so können diese von manchen Boxen nicht dargestellt werden. So definieren mache Boxen einen Programmplatz nur über Kennung, SID und zugehörigen Transponder. Machen Boxen ist die TSID z.B. auch vollkommen egal, andere bringen ein Schwarzbild wenn die nicht stimmt. Andere verkraften es nicht wenn die TSID/ONID Kombination nicht eindeutig ist usw. Ist aber nur eine Abstimmungs frage. Was Billy angeht ist mir das relativ Wurst, nur sollte das Format nicht von einem Browser abhängig sein. Sollte auch System übergreifend sein nicht nur in der PC Welt laufen...
Kann meinetwegen sogar ein Hexformat sein. Nur es muß angenommen werden, es hilft nichts wenn wir das in unsere Editoren einbauen und kein anderer macht mit.
cu oli

Nun ja,
Ziel ist es wohl, jegliche Editoren von Herstellern nur noch zum Senden und Empfangen der Settings zu benutzen - bearbeitet werden sie dann mit dem Standardeditor.

Glaube ich nicht so. Denke eher das es dazu dienen sollte Standard Settings im Netz zu ziehen und dann mit den Hersteller-Editoren auf das Gerät abzustimmen und dann einspielen. Manche Hersteller weigern sich auch APIs raus zu geben, also nur Hacker Editoren verfügbar... Wenn ich nur sehe wie gut Updates von SatCODX ... funktionieren. Viele Hersteller Editoren sind sehr gut auf die Geräte Mucken abgestimmt.
Wir sollten mal an die Definition gehen?
cu oli

@Oli
Bezüglich der Allgemeingültigkeit siehe W3C, der "Regulierungsbehörde" für Internet-Standards.
http://www.w3.org/XML/

insbesondere den Punkt 10 (leider Alles nur in Englisch) unter
http://www.w3.org/XML/1999/XML-in-10-points

Eine deutsche Übersetzung der Definition von XML 1.0 gibt's unter http://www.mintert.com/xml/trans/REC-xm ... 10-de.html

Für die Daten/Struktur-Definition hat das W3C "XML Schema" vorgeschlagen. Aktueller Status: Candidate Recommendation (Feedback Ende: Dezember 2000).
http://www.w3.org/XML/Schema.html und dort http://www.w3.org/TR/xmlschema-0/

Müsste also bald was "Endgültiges" kommen.
Dies betrifft allerdings "nur" die Formulierung einer korrekten XML-Vorlage zur Instanzierung (Brrrr!) der jeweiligen (zu verarbeitenden) Datenbestände.

Um (mit Definitionen) Niemanden abzuschrecken, sollte man wirklich einfach mal an die Sammlung von Daten und Struktur gehen.

Bei meinen Humax-Daten kann man folgende Struktur erahnen:

Satellit (Antenna)
Netzwerk (Network)
Provider (~)
Transponder (TS)
Programm (Service)

und zum Abschluß noch geräteabhängig und hier unwichtig: Menü

Zuerst muß entschieden werden, ob diese Struktur sinnvoll und vollständig ist, dann kann zu Jedem dieser Objekte eine (möglichst vollständige) Menge von Daten (Eigenschaften) zusammengetragen werden.

Danach erst sollte man sich mit Vorlage und deren syntaktischer Formulierung beschäftigen.

Warum wird das nur immer so lang?
Janus

Unter
http://www.xmlspy.com

gibt's ein heißes Tool (3.5 Beta 4, 30Tage bei EvalRegistrierung, Download 8,2 MB)

DSL erst IV/01!! Sauer!!

Janus

Satellit (Antenna)
hier gibt es zwei Möglichkeiten. Humax und andere definieren hier Antenne mit 1 bis 8 oder 1 bis 4. Andere haben eine direkte Zuordnung mit Benennung z.B. $0192 Astra; $0130 Hotbird. Teilweise erfolgt hier noch eine Unterscheidung E ost oder W west. Dies ist dann direckt in das Menü Antenneneinstellung integriert. Währe aber kein Problem den Nutzer eines Humaxeditor die Auswahl zwischen Astra... statt 1 - 8 zu geben, wenn man das extra definiert.

Netzwerk (Network)
Dies soll wohl eine Art Bouquetlist oder Favoritenliste sein? Mache Hersteller haben hier eine Extra Liste analog der Serviceliste. Andere definieren aus der Serviceliste heraus nur über 1 oder 2 Kriterien. Manche Boxen definieren hier wahlweise den automatischen Start des EPG (RTL World, ARD EPG...).

Provider (~)
Wird vielmals gar nicht angelegt. Bei mir hier nur als zusätzlichen String innerhalb der Servicelist

Transponder (TS)
ONID/TSID/Freq./SR/FEC/Pol./Ant./Name

Programm (Service)
Hier haben mache Boxen einen "All" Liste mit Audio und Video, andere wieder haben zwei Grundlisten. Allgemein aber
ONID/TSID/SID/Typ/Codeflag/Servicename/Providername

Wir sollten die Kriterien unserer Boxen mal nebeneinander legen und sehen was hier vergleichbar ist.
cu oli

Die Strukturbeschreibung für Humax (5x00 usw.) befindet sich in der API-Dokumentation (Version 0.90) hier:
http://www.humaxdigital.com/support/Fil ... AK(English).zip

Mehr weiß ich auch nicht.

Janus