Next Generation Channelmanagment (Service UI)

[Darwin]

Ich habe mir in meiner kleinen Ecke mal ein paar Gedanken gemacht über eine eventuelle Optimierung der Senderverwaltung - eine 'Weiterentwicklung' von DVBViewer ist ja kurz angesagt worden - und der Flexibilität in dem damit eng verbundenen User-Interface.

 

Ich würde den ganzen Komplex in drei entkoppelte Bestände trennen:

 

A: Eine Beschreibung der Technik. (Empfangseinrichtung, Schaltwege, verbaute Devices)

B: Eine leicht aktualisierbare DVB-only Senderliste (ohne "ordnenden Zugriff" durch den User) zum Tunen eines gewählten Services.

C: Eine "Formulierung" der User-Wünsche, also die individuelle Anordnung in "Senderliste" oder OSD.

 

Die Verbindung zwischen den 3 Beständen wird über (wirklich) eindeutige Referenzen gehalten, die in großen Bereich schon durch die DVB-Dokumente vorgegeben sind.

 

 

zu A:

Hier wird letztlich der Weg von der Service-"Quelle" bis zum auswertenden Gerät (Device) beschrieben.

 

Aus der Sicht der Applikation ist es damit möglich, einen gewählten Service aus einer User-Liste einem 'potenten' Device (der auch tatsächlich Zugriff auf die passende Quelle hat) zuzuweisen und mit Hilfe der 'Wegbeschreibung' (z.B. DiSEqC-Kommandos, Tunerauswahl etc) den Zugriff auf diese Quelle korrekt 'einzustellen'.

 

Als Referenzen kommen hier 'indizierte Signalwege', Liefertypen entsprechend der verwendeten Technik (C,S,T,H,I...) und indizierte Lieferanten (Sat-Positionen, Netzbetreiber u.Ä) zum Einsatz.

 

 

zu B:

In einer Datenhaltung, deren flexible, hierarchische Struktur einerseits an die DVB-Dokumente/SI-Tabellen - andererseits an die 'Summe' der durch die Devices definierten Optionen angepasst ist, kann durch entsprechende Suchläufe oder durch Import aus verschiedensten Quellen (Webservices, Kumpel) der aktuell verfügbare Stand an Services ohne direkten Einfluß auf A oder C bereitgehalten werden. Da die SI-Tabellen für ein und denselben Service ja 'überall' gleich sind, sollte das einfach zu machen sein. Ein geeignetes Werkzeug (TransEdit.Analyzer) für den Heimanwender existiert ja auch schon, sollte per XSL-Transfomation und Erweiterung auf "Analyze.Bereich" recht leicht anzupassen sein

 

Die Referenzen innerhalb dieser Daten sind Liefertyp und 'Lieferanten'-Index (in Richtung A) sowie die durch die "DVB-Papiere" vorgegebene Addressierung, bei Sat z.B. über ONID, TSID und SID. Das sollte - abgesehen vielleicht von ganz fieseligen temporären Feeds - eindeutig zu einem einzigen Service zeigen. Für SatDX-Hardliner ließe sich da vielleicht auch noch eine geeignete 'Krücke' aus Frequenz, Polarisation, Symbolrate und FEC finden.

 

 

zu C:

Die Schnittstelle zum User-Interface bilden frei konfigurierbare (und auch beliebig strukturierbare) 'User'-Daten, die für den Zugriff die Referenz auf den Service (in B ) und evtl. auch schon die Referenz auf die Empfangseinrichtung beinhalten.

Zu dem so referenzierten Service können dann - auch hier wieder abhängig von den Optionen des Devices und zusätzlich den persönlichen Wünschen des Users - weitere Properties verwaltet werden, die die Device-Optionen und Selektions- und/oder Sortierkriterien für den User darstellen. Beispielhaft kann ich hier mal Audiofeed-Vorgabe (APID) als Device-Option und einen frei definierten Genre-Verweis oder FriendlyNames als User-Optionen anführen.

 

 

Ich selbst würde diese durchweg hierarchisch organisierte Datenbestände in (ebenfalls hierarchischem) XML formlieren, was einerseits die notwendige Flexibilität (auch keine Längenbeschränkung bei Strings ) und Erweiterbarkeit gestattet, andererseits durch die Tags das Ganze für den HyperPower-User auch human-readable macht.

Auf einem HDTV-fähigen PVR-PC sollten auch Anti-XML Argumente wie zu groß, zu langsam, keine wirkliche Rolle spielen.

XML-Parser sind in modernen Programmiersprachen Usus und durch die Möglichkeiten einer solchen Auszeichnungssprache sollten sich auch große Teile des eigentlichen User-Interface auf deklarativem Wege lösen lassen. Bei CodeProject gibt es z.B. eine C#-Lösung von Marc Clifton, wie man einen 'XML-Datenbank'-Editor nur über ein extern vorhandenes Schema generiert. Ich habe das mit meiner eigenen ServiceDB getestet, es funktioniert. Aufwand für eine Anpassung durch Änderungen in der Datenbank-Struktur ist dann fast vernachlässigbar. (Ein neues Attribut (z.B. FriendlyNames in der Userdatei ist eine einzige zusätzliche Zeile in der Schemadatei <xs:attribute fname="name" type="xs:string" /> und schon passt der Editor wieder auf den Datenbestand)

 

 

Ich meine, man könnte mit diesem Konzept so ziemlich Alles erschlagen was DVB-mäßig ansteht.

Für IPTV und DVB-H - außerhalb meiner Ecke - fehlen mir zwar Informationen, aber das Prinzip sollte auch dort funktionieren, wenn man geeignete Referenzwerte hat oder reproduzierbar erzeugen kann.

 

Nur mal so, als Denkanstoß!

 

 

 

Hey,

ich habe keine bessere Stelle gefunden! Die Beta-Sektion schien mir ein wenig übertrieben.

Also schiebt es, wohin es auch immer passt.