Datenbank für den Settings-Download

[essu]

Vllt kennt die eine oder der andere mein Plugin 'getset' mit dem man Satelliten-Settings downloaden kann, was erheblich weniger Zeit in Anspruch nimmt (1-2 min für Astra und Hotbird) als ein Satelliten-Scan.

Was mir daran aber nicht gefällt ist folgendes:

- die Settings sind nur für Sat, Kabelnutzer profitieren nicht davon
- die Settings kommen von dewi-Sat, einem letztlich kommerziellen Unternehmen, auf die Datenbankseite gibt es keinen Einfluss
- das Plugin ist ein reines shell-script und nicht in die GUIs integriert

Was ich mir nun vorstelle, ist eine Datenbank auf einem 'tuxbox-eigenen' Server, die mit den Settings aller linux@dbox-Nutzer/innen gespeist wird. Dazu sollte es in den Satelliten-Scan-Menues die alternative Möglichkeit 'Settings downloaden' geben. Wird dieser ausgewählt, werden die vorhandenen Settings an die Datenbank geschickt und mit den dort gespeicherten verglichen. Noch nicht in der Datenbank vorhandene Kanäle werden dort ergänzt, noch nicht auf dem Receiver vorhandene Kanäle werden dort in einem Bouquet 'new' angezeigt.

Meine Fragen sind nun,
- ob überhaupt Interesse an so einem Service besteht,
- ob die tuxDEVs sich vorstellen können, sowas in die GUIs zu übernehmen und
- wer Interesse hätte, an diesem Projekt mutzuwirken und z.B. das Datenbank-Layout übernehmen könnte

[gooofi]

ist das die option "Settings-Download" unter blau\1?
falls dem so ist, dann weiß ich jetzt endlich auch mal das ich davon die finger lassen sollte (1x probiert und meine kanalliste war futsch/bin kabeluser, der aber ein backup aller seiner settings hatte )

also ich finde die idee gut, wenn ich oft hier lese, dass viele member keine/wenige sender finden. ich habe hier zum glück keine probleme, aber mit einem solchen service kann man dann ja sicher sein alles in der liste zu haben was verfügbar sein sollte.

in diesem sinne: prädikat "sinnvoll"

[Sepp776]

dazu fällt mir ein, dass es für Kabeluser etwas schwierig sein könnte, weil es da ja zig unterschiedliche Anbieter gibt. Könnte mir vorstellen, dass die Pflege recht aufwändig ist...

[essu]

dazu fällt mir ein, dass es für Kabeluser etwas schwierig sein könnte, weil es da ja zig unterschiedliche Anbieter gibt. Könnte mir vorstellen, dass die Pflege recht aufwändig ist...

...das soll sich ja 'selber pflegen'. Wenn ein User mit einen neuen Anbieter kommt sollen seine Daten in die db übernommen werden.

[Janus]

Was gut ist kommt immer wieder?

Ist aber nicht ganz so einfach, wie es sich im ersten Moment anhört!
Leider sind die Folge-Threads auf Satpage der dortigen Umstrukturierung (Domain-Wechsel) zum Opfer gefallen. Habe aber sporadisch daran weitergebastelt.

Wer wäre dafür zuständig? Könnten uns mal austauschen...

Janus

[essu]

Wer wäre dafür zuständig? Könnten uns mal austauschen...

Du kannst dich an mogway oder mich wenden, am besten im IRCnet #yadi, ansonsten natürlich auch in diesem thread, damit alle etwas mitbekommen

[Janus]

"Mein" Langzeit-Projekt ist mehr 'ganzheitlich' angelegt.

Ich (= mein zukünftiger universeller Editor) verwaltet eine lokale Datenbank mit den für mein Equipment relevanten Daten.
Über Vorlagen (für User und Receiver) werden daraus entsprechende Settings generiert.

Nach dem Motto: Generiere Wohnzimmer-Settings für SagemNeutrino werden services.xml und bouquets.xml erstellt, wenn ich meine Sagem aus dem Büro wieder ins Wohnzimmer stellen will.
Der Humax wandert ins Büro, daher dann: Generiere Test-Settings für HumaxOAK (erzeugt Test.hnf)

Durch die Verwendung von XML und C# verspreche ich mir nach Fertigstellung eine plattformneutrale Anwendung.

Der Editorkern selbst verwaltet die Datenbank und die User-Vorlagen. Über receiverspezifische Plugins werden die Formatvorgaben und die proprietären Dinge (load/save, read/write, scan, check) gehandelt.

Die Pflege der lokalen XSDB (eXtensible Service DataBase) soll über mehrere Optionen erfolgen:
- Verwendung vorhandener Scan-Optionen (selbst gescannte Settings oder direkter Zugriff auf die Firmware als 'Lieferant')
- Anbindung an eine zentrale Datenbank (daher meine 'Meldung')
- Auslesen/Ausnutzen geeigneter DXer-Sites (SatCoDX, LyngSat)
- manuelle Bearbeitung

Daraus ergibt sich, daß sich der Gesamtdatenbestand (auch wegen entsprechender Selektions-Kriterien) nicht auf den in Neutrino geführten Bestand reduzieren lässt. Also auch nicht ohne Weiteres aus vorhandenen Settings pflegen lässt!

Ich habe hier mal eine Grundstruktur angedacht, die zumindest den Bedarf für's Tuning (mehrerer Receiver-Plattformen) abdeckt.

Dazu gehören die folgenden Vorüberlegungen (aus einem anderen Thread):
- - - -
Die Generierung von Settings beruht auf Daten aus drei Bereichen:
- Die DVB-spezifischen Daten, die für das eigentliche Tuning benötigt werden.
- Die IRD-spezifischen Daten, die für die (physikalische) Abstimmung zwischen Receiver und Empfangseinrichtung notwendig sind.
- Die User-spezifischen Daten, die Organisation (Selektion/Sortierung/...) der "persönlichen" Services gestatten.

In manchen Bereichen sind Überschneidungen.
So können z.B. Provider/Bouquet-Zuordnungen (DVB) zur Gruppierung (User) benutzt werden.
Oder Receiver mischen DiSEqC-Parameter (IRD) direkt mit Sat-Positionen (DVB).

Der Editor als zentrales (und lokales!) Werkzeug für den User muß dieser Einteilung bezüglich eines zentralen Datenangebots folgen.
IRD- und User-Vorlieben können nicht zentral verwaltet werden!

1) Eine Online-Datenbank muß alle für die Zielreceiver relevanten DVB-Daten liefern!
Wobei der Umfang der Datensätze mit Erscheinen neuer Receivertypen oder weiterer Services natürlich häufig angepasst werden müsste, wenn man sich zu Beginn auf einige Receivertypen (und deren "Bedürfnisse") beschränkt. Wichtig ist aber die Eindeutigkeit. Der abfragende Editor muß sicher zuordnen können.

2) Eine Online-Datenbank soll, über die im DVB-Stream gesendeten [Provider/Sprache/...] hinaus, weitere Selektionskriterien enthalten.
Das macht das Online-Angebot attraktiv und den Traffic kleiner. Abfragen wie etwa "Alle unverschlüsselten englischsprachigen TV- und Radio-Services von 40°Ost bis 20°West, die nach dem 01.04.2003 verändert wurden" sollten möglich sein. Solche zusätzlichen Kriterien können gemeinsam mit den Usern festgelegt werden.

3) Weiterhin müssen natürlich alle datenbankinternen Werte (Indizes, TimeStamps, Locking, Stati ...) sein.
Das ist aber abhängig von dem gewählten DBMS (und dem Admin ) Unbedingt berücksichtigt werden muß dabei die Möglichkeit der externen Pflege durch eingewiesene User, die Aktualisierungen am Bestand übernehmen wollen. Das wäre aber erst der zweite Schritt.


Nach der Festlegung der Datenstrukturen wäre der Transport zu 'organisieren'. Wobei unter Umständen Wechselwirkungen mit dem zu wählenden DBMS auftauchen. Sollte man also bereits im Vorfeld gemeinsam betrachten.

Ich persönlich würde das Ganze als WebService projektieren.
Das bedeutet:
- Weitgehende Plattformunabhängigkeit durch definierte Protokolle
- Plattformunabhängigkeit der transferrierten Daten (XML)
- weitere Managment-Optionen (getrennte Berechtigungen für DL/UL, später vielleicht mal Abrechnungen) sind/werden Bestandteil der Protokolle
Bedeutet allerdings entsprechende Server-Ausstattung.
- - - -

Nur mal so als Diskussionsgrundlage...
Und: Ich bin über's Denken und Ausprobieren noch nicht sonderlich weit rausgekommen

Janus