vorschlag zu den xml-senderlisten

Beitrag von **zor** » Samstag 15. Juli 2006, 15:23

hi @all !

habe eine idee zur vereinigung der satellites.xml, services.xml und myservices.xml zu einer einzigen datei der besseren wartbarkeit und optimierung wegen:

idee 1:
vereinigung aus satellites.xml und services.xml. beide haben ähnliche struktur, vergleichen wir mal:

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat name="19.2E ASTRA 1C,1E,1F,1G,1H,2C" flags="5" position="192"> 
<transponder frequency="10773250" symbol_rate="22000000" polarization="0" fec_inner="5"/>
<transponder frequency="10788000" symbol_rate="22000000" polarization="1" fec_inner="5"/> 
<transponder frequency="10817500" symbol_rate="22000000" polarization="1" fec_inner="5"/> 
<transponder frequency="10832250" symbol_rate="22000000" polarization="0" fec_inner="5"/> 
<transponder frequency="10847000" symbol_rate="22000000" polarization="1" fec_inner="5"/> 

<?xml version="1.0" encoding="UTF-8" ?>
<zapit>
<sat name="Astra 19.2E" diseqc="0" position="0192">
<transponder id="041e" onid="0001" frequency="10788000" inversion="0" symbol_rate="22000000" fec_inner="5" polarization="1">
<channel service_id="768e" name="TAQUILLA 1" service_type="01" />
<channel service_id="768f" name="TAQUILLA 2" service_type="01" />
<channel service_id="7690" name="TAQUILLA 3" service_type="01" />

der grund warum es aus meiner sicht fein wäre die beiden zu vereinigen
ist folgender:

1) das verlust-problem:
in der nit sind ja bekanntlich die transponderinfos zum satelliten enthalten. während bei astra die nit noch halbwegs gut gepflegt ist, ist das überall außerhalb von 19.2E anders. da fehlen in der regel jede menge transponder, sind transponder falsch eingetragen, wechselt die nit von transponder zu transponder etc.
daher hat man in die satellites.xml auch noch die transponder eingetragen (oder zumindest ein paar). das hilft einem beim suchlauf - man findet mehr sender! hat man den sectionsscan am laufen, so kommen mit der zeit vielleicht noch ein paar transponder dazu!
macht man nun aber einen neuen sendersuchlauf, weil der letzte vielleicht schon 3 monate her ist, so wird wieder die nit und die transponder aus der satellites.xml ausgewertet. viele transponder aus der services.xml (welche der sectionsscan mal gefunden hat oder welche mal manuell in die services.xml reingemacht hat) gehen verloren

lösung: sind beide vereinigt, so geht nichts verloren - alles bleibt am aktuellen stand!!

2) das nit-frequenzproblem
viele transponder aus der satellites.xml tragen die lyngsat-frequenz, aber nicht die nit-frequenz. es gibt keine große datenbank (lyngsat, kingofsat, satcodx, etc) welche die nit-frequenzen pflegt!! hat man den sectionsscan am laufen, so kann es passieren, dass der in der services.xml die frequenz auf die nit-frequenz abändert. zb von 10832000 auf 10832250 wie oben angeführt. somit stimmt die frequenz zwischen
services.xml und satellites.xml nicht mehr überein!

lösung: sind beide vereinigt, so wird zugleich die satellites.xml aktualisiert!!

3) es fehlt generell eine kennung, ob es sich nun um eine nit-frequenz handelt, oder um einen manuellen eintrag!

4) eine vereinigung spart platz!

daher mein vorschlag (für einen transponder) wie das ganze aussehen könnte:

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat name="19.2E ASTRA 1C,1E,1F,1G,1H,2C" flags="5" position="192"> 
<transponder frequency="10788000" symbol_rate="22000000" polarization="1" fec_inner="5" id="041e" onid="0001" nit="1"/> 
<channel service_id="768e" name="TAQUILLA 1" service_type="01" />
<channel service_id="768f" name="TAQUILLA 2" service_type="01" />
<channel service_id="7690" name="TAQUILLA 3" service_type="01" />

ich denke das flags="" könnte man sich sparen. das hat die funktion (soweit ich mich erinnere) festzulegen welche transponder eines satelliten bei einem scan durchsucht werden dürfen. die aus der satellites, die aus der nit, oder beides. an sich ist da immer beides empfehlenswert - man will ja möglichst viel finden! weiß nicht welchen schutz das bieten soll? vielleicht vor korrupten nits, aber das kann man sicher anders auch überprüfen..

eine freude wieviel platz gespart wurde und alles doch irgendwie gleich aussieht! eine nit-kennung bereitet dem bouquetersteller freude! eine neue satellites.xml in einem yadi etwa enthielte nur die satelliten und transponder - die sender sucht sich jeder selbst! vor verloren gegangenen satellites.xml braucht man sich auch nicht zu fürchten, das könnte man ja automatisiert backuppen...

idee 2:
vereinigung aus (services.xml+satellites.xml) und myservices.xml

sehen wir uns auch mal die beiden an!

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat name="19.2E ASTRA 1C,1E,1F,1G,1H,2C" flags="5" position="192"> 
<transponder frequency="10788000" symbol_rate="22000000" polarization="1" fec_inner="5" id="041e" onid="0001" nit="1"/>
<channel service_id="768e" name="TAQUILLA 1" service_type="01" />
<channel service_id="768f" name="TAQUILLA 2" service_type="01" />
<channel service_id="7690" name="TAQUILLA 3" service_type="01" />

<?xml version="1.0" encoding="UTF-8" ?>
<zapit>
<sat name="Astra 19.2E" diseqc="0">
<transponder id="041e" onid="0001" frequency="10788000" inversion="2" symbol_rate="22000000" fec_inner="5" polarization="1">
<channel service_id="768e" action="replace" name="Taquilla 1 ESP/ORG" service_type="01" />
<channel service_id="768f" action="replace" name="Taquilla 2 ESP/ORG" service_type="01" />
<channel service_id="7690" action="replace" name="Taquilla 3 ESP/ORG" service_type="01" />
<channel service_id="7691" action="replace" name="Taquilla 4 ESP/ORG" service_type="01" />

sehen ja auch verdammt ähnlich aus. nun was gibt es da für probleme:

1) platzbedarf
alleine an diesem kurzem bsp erkennt man deutlich wieviel mehr an platz
man benötigt, wenn man jeden sender umbenennt. das macht sicher nicht
jeder, aber mir (und vielen nutzern meiner listen) gefällt das sehr gut!

2) die übersicht
ich bin ein bouquetlisteersteller vom alten schlag, mache alles manuell!
nun habe ich dann links die services und rechts die myservices und dann
wird rechts und links nach oben und unten verschoben. bis halt alles
paßt. schön wärs, würde alles in dergleichen zeile geschehen..

3) altlasten in den bouquets
des öfteren mache ich einen sendersuchlauf nach welchem dann manche
sender aus der services rausfliegen. da ich fast alle sender umbenenne
habe ich dann noch den eintrag in der myservices drinnen. über das log
findet man dann zwar raus, was nicht paßt, aber ist auch nicht elegant.
schlimm sind sender, welche einfach ihren namen ändern, aber nicht die
sid. das bekommt man in der regel nämlich gar nicht mit. ob's da nicht
eine feine lösung gäbe?

jetzt mein vorschlag für eine komplett vereinigte senderliste:

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat name="19.2E ASTRA 1C,1E,1F,1G,1H,2C" flags="5" position="192"> 
<transponder frequency="10788000" symbol_rate="22000000" polarization="1" fec_inner="5" id="041e" onid="0001" nit="1"/> 
<channel action="" service_id="" name="" rename="" service_type="" real_service_type=""/>
<channel action="" service_id="" name="" rename="" service_type=""/>
<channel action="" service_id="" name="" rename="" service_type=""/>

auf den ersten blick werden hier die probleme 1 und 2 gelöst. das ganze
ist kompakt und übersichtlich! interessant ist das action="", zu welchem
ich mir ein wenig was überlegt habe. es ist anders als das action="",
welches in der myservices.xml verwendet wird!

action="check"
hier gabs eine änderung - bitte checken! wird vom scan erzeugt! durch das check-flag ist die sid somit geschützt und sichtbar(oder besser rename="" und real_service_type="" sind geschützt) selbst bei fehlender kennung soll das check-flag bleiben. entspricht also einem "fixed", soll aber dazu anregen nachzusehen..name="" und service_type="" dürfen natürlich verändert werden.
kommt also ein sender hinzu oder weg wird action="check" eingefügt. ändert ein sender die kennung so wird ebenfalls action="check" eingefügt! löst somit problem 3

action="ignore" ignoriert eine sid permanent. selbst wenn die kennung nicht mehr da ist. es gibt so "lästige" sender die permanent auftauchen und dann wieder weg sind, aber im grunde unnötig sind.. entspricht dem action="remove" (rename="" ist geschützt, damit der bouquetmeister der wechselnden kennung einen namen geben kann) name="" und service_type="" dürfen natürlich verändert werden

action="penalty" (vergibt eine strafzeit) ignoriert einen sender solange bis es eine änderung bei name="" oder service_type="" gibt! name="" und service_type="" würden dann überschrieben, rename= und real_service_type= aber nicht. nach der änderung wird action="check" gesetzt. der eintrag entspricht einem remove auf zeit

action="fixed" fester eintrag, zb bsp premiere feed, wo mal eine kennung da ist und dann wieder nicht. entspricht einem action="add" (rename="" und real_service_type="" sind geschützt). eine änderung bei name= oder service_type= ruft kein action="check" hervor.

ein paar weitere bemerkungen:

das action="replace" wo immer name und service_type zugleich überschrieben werden kann man sich sparen, da entweder name oder service_type überschrieben werden (man denke nur wie selten der service_type verändert werden muss)...man denke weiters, dass man für die myservices keine transponder mehr erstellen muss...

rename="" real_service_type=""
erklären sich wohl von selbst. name und service_type bleiben immer drinnen, damit man in einer zeile immer vergleichen kann was man verändert hat. das ist das allerschönste für einen bouquetersteller wie mich ;-)

bei rename könnte man sogar was von den enigma-senderlisten übernehmen - und zwar, dass 2 namen in einem dargestellt werden können:
rename="{Premiere 1{ D/ORG}}" kann heißen:
Premiere 1 - short
Premiere 1 D/ORG - long

ich meine, dass so vieles vereinfacht würde. ich schätze mal grob den arbeitsaufwand für den ersten schritt, der vereinigung von satellites.xml und services.xml, nicht als sehr groß ein, da ja "nur" eine andere datei geparst werden muss. hoffentlich sehe ich das nicht zu einfach ;-)
der 2.schritt sollte vom parsen her nicht schlimm sein, aber das umgestalten der action="" würde wohl mehr zeit in anspruch nehmen.

nun, nach so vielen vorschlägen auf einmal und der ganzen euphorie meinerseits lasse ich euch devs zu wort kommen...

gruss zor

Beitrag von **Gorcon** » Sonntag 16. Juli 2006, 08:44

Und wie willst Du es schaffen auch noch die cables.xml in das Format zu bringen?

Gruß Gorcon

Beitrag von **zor** » Montag 17. Juli 2006, 00:31

@gorcon

so etwa: aus der cables.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<cables>
<cable name="Kabelcom Rheinhessen">
<transponder frequency="394000000" symbol_rate="6900000" fec_inner="9" modulation="3"/>
<transponder frequency="402000000" symbol_rate="6900000" fec_inner="9" modulation="3"/>
<transponder frequency="410000000" symbol_rate="6900000" fec_inner="9" modulation="3"/>

und der services.xml

<cable name="Kabelcom Rheinhessen">
<transponder id="0437" onid="0001" frequency="394000000" inversion="2" symbol_rate="6900000" fec_inner="9" modulation="3">
<channel service_id="6d66" name="ZDF" service_type="01"/>
<channel service_id="6d67" name="3sat" service_type="01"/>
<channel service_id="6d68" name="KiKa" service_type="01"/>
<channel service_id="6d69" name="Eurosport" service_type="01"/>

würde eine verallgemeinerte:

<?xml version="1.0" encoding="UTF-8"?>
<cables>
<cable name="Kabelcom Rheinhessen">
<transponder frequency="394000000" symbol_rate="6900000" fec_inner="9" id="0437" onid="0001" inversion="2" modulation="3"/>
<channel action="" service_id="" name="" rename="" service_type="" real_service_type=""/>

so hätten auch die leute, welche am kabelnetz hängen, ebenfalls statt 3 dateien nur noch eine...

gruss zor

Beitrag von **Nirvana** » Montag 17. Juli 2006, 07:31

Also ich halte das Format auch für reformationswürdig. Allerdings läuft mein Wunsch in eine andere Richtung. Mich stört, dass ich die services.xml nicht von Box A nach B kopieren kann, weil die Diseqc-Einstellungen nicht passen.

Deshalb hätte ich gerne eine Datei, in der nur Verweise stehen a la:
diseqc0=192E.xml
diseqc1=130E.xml
...

Dann könnte man die 192E.xml universell verwenden oder sogar an zentraler Stelle im Internet pflegen.

Können wir unsere Vorstellungen irgendwie miteinander vereinbaren?

Beitrag von **zor** » Montag 17. Juli 2006, 14:33

@nirvana

ich bin auch generell dafür, dass die diseqc-einstelllungen rausfliegen und in eine eigene datei sollen. etwa:

diseqc.xml

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat position="192" diseqc="0">
...

..somit könntest du deine services.xml von einer box zur anderen kopieren, denn die diseqc-werte sind in einer eigenen datei..

Dann könnte man die 192E.xml universell verwenden oder sogar an zentraler Stelle im Internet pflegen.

wer sagt, dass das nicht passiert ;-)

ob ein aufteilen der .xmls sinnvoll ist überlege ich mir jetzt beim essen.. ;-)

gruss zor

Beitrag von **Barf** » Montag 17. Juli 2006, 15:10

Ein Paar unsortierte Bemerkungen:

die drei Dateien satellites/cables.xml, services.xmk, myservices.xml sind dadurch motiviert, weil die Daten drin unterschiedliche "Eigentümer" haben: satellites/cables.xml: Maintainer/User, services.xml: Das System, wird bei scan neu geschrieben; myservices.xml: der User. Es is möglich, dass "Eigentümerproblem" anders zu lösen; fordert aber etwas Coding!

Diese Dateien sind keine empfohlene Benutzerschnittstelle, sonden sind für Programme da. Deswegen halte ich z.B. "Übersichtligkeit" nicht für eine eigenliche Anforderung. Für Übersichten kann mann ein Progrämmchen schreiben, z.B. in XSLT. Stichwort: Reportgenerator.

Was ich gerne machen möchte:
Selbst möchte ich gerne die libxml2-bibliothek in Neutrino/zapit benutzen, statt das fürchterliche xtree-Frickeln. (libxml2 ist in CVS, wird aber z.Z. nur von LCARS(!) benutzt.) Mann könnte dabei, z.B. die xml-datenbanken beim Lesen/Schreiben "on-the-fly" komprimieren. xincludes könnte intressant sein, wurde (am mindestens teilweise) der Bedarf für myservices.xml eliminieren. Weiter: DTDs für die Dateien definieren und benutzen; die Dateien sollen dann vom validierende Parser (libxml2!) geparst werden. Dabei bekommt mann die (syntaktische) Probleme sofort in Griff.

Übrigens habe ich sein etwa ein Jahr das Verfassens eines XML-Tutorials auf meiner TODO-Liste:

Beitrag von **usul1** » Montag 17. Juli 2006, 16:08

Nur einige Anmerkungen aus reiner Benutzer Sicht.

Barf hat geschrieben:services.xml: Das System, wird bei scan neu geschrieben;

Allerdings beist sich das mit den Favoriten.

Es ist IMHO etwas unglücklich gelöst das die Favoritenlisten dardurch zustandekommen das ich in der bougets.xml (die gehört ja direkt zur services.xml. Wobei IMHO die Bougetzugehörigkeit als Atribut in die services.xml gehört hätte und die Bouget.xml eigentlich überflüssig ist) rumeditiere.
Im Moment ist ja z.B. ein Scan ja garnicht möglich ohne nacher mit einem Editor die Favorieten wieder einzufügen.

IMHO sollte die Favoritenlisten von der eigentlichen Senderliste getrennt werden.

Barf hat geschrieben: Diese Dateien sind keine empfohlene Benutzerschnittstelle, sonden sind für Programme da.

Warum dann aber XML? Wäre es nicht sehr viel einfacher, Playtzsparender und schneller diese Sachen in irgendeinem Binären Format zu speicher?

Man kann ja trotzdem eine Lib einbauen die das private Senderlisten Format nach irgendeinem XML wandelt und umgekehrt (so das z.B. ein Services.xml download über das Web Interface "on the Fly" nach XML konvertiert). So das man (z.B. ein Bougeteditor) trotzdem mit XML Dateien arbeiten könnte (als einheitliche Schnittstelle) aber das Speichern privat in irgendeinem Binärformat stattfindet.

cu
usul

Beitrag von **zor** » Montag 17. Juli 2006, 21:35

@barf

die drei Dateien satellites/cables.xml, services.xmk, myservices.xml sind dadurch motiviert, weil die Daten drin unterschiedliche "Eigentümer" haben: satellites/cables.xml: Maintainer/User, services.xml: Das System, wird bei scan neu geschrieben; myservices.xml: der User. Es is möglich, dass "Eigentümerproblem" anders zu lösen; fordert aber etwas Coding!

kann man nicht für die neue vereinigte satellites.xml den user als eigentümer setzten? was soll denn großartig passieren wenn die neue satellites.xml durch grep und sed (oder wie auch immer) verändert wird? das funktioniert doch auch sonst ganz ausgezeichnet...
mit einem satellites.xml.backup.tar.gz ist man immer auf der sicheren seite..

Diese Dateien sind keine empfohlene Benutzerschnittstelle, sonden sind für Programme da. Deswegen halte ich z.B. "Übersichtligkeit" nicht für eine eigenliche Anforderung. Für Übersichten kann mann ein Progrämmchen schreiben, z.B. in XSLT. Stichwort: Reportgenerator.

da ich bisher kein programm für linux kennengelernt habe ist die datei selbst benutzerschnittstelle für mich...

@usul1

Allerdings beist sich das mit den Favoriten.

IMHO sollte die Favoritenlisten von der eigentlichen Senderliste getrennt werden.

habe zwar noch nie eine liste mit favouriten erstellt, aber die sind doch nicht in der services.xml? denke mir ja generell warum man favouriten braucht, wenn man sich eine schöne bouquets.xml zusammenstellen kann...

Wäre es nicht sehr viel einfacher, Playtzsparender und schneller diese Sachen in irgendeinem Binären Format zu speicher?

ich denke zum einen werden die listen vom webinterface geparst und zum anderen ist die datei dadurch in einem format, welches man auf den ersten blick versteht!

gruss zor

Beitrag von **usul1** » Dienstag 18. Juli 2006, 10:27

zor hat geschrieben:
IMHO sollte die Favoritenlisten von der eigentlichen Senderliste getrennt werden.
habe zwar noch nie eine liste mit favouriten erstellt, aber die sind doch nicht in der services.xml?

Die sind in der bougets.xml. Und diese gehört ja untrennbar zur services.xml (Die bougets.xml enthält ja als einzige Information zu welchem Bouget ein Service gehört). Wie untrennbar die verbunden sind zeigt sich ja wenn man die bougets.xml editiert. Dann funktioniert das ganze System ja nicht mehr richtig (z.B. springt Neutrino bei Sendern die in zwei Bougets sind nach einem reload der Senderlisten auf den falschen Sendeplatz).

zor hat geschrieben:denke mir ja generell warum man favouriten braucht, wenn man sich eine schöne bouquets.xml zusammenstellen kann...

Es gibt vermutlich mehre bevorzugte Methoden sowas zu handhaben ;-)

Ich betrachte die Senderliste als eine Datenbank von allem was auf den Sateliten die ich empfange vorhanden ist.
Die Favoritenlisten sind die Sender die ich nutze. Also im Normalfall zappe ich über meine Favoriten. Höre ich z.B. in einem Forum "Schau mal hier den Sender, da ist..." möchte ich natürlich auch die Möglichkeit haben schnell einen bestimmten Sender anzuspringen der nicht in den Favoriten ist (BTW: Das geht im Moment ja auch sehr schlecht da eine Darstellung alle Sender in Alphabetischer Reihenfolge fehlt).

Desweiteren braucht das System ja eine komplette Senderliste (inklusive der orginal Bouget zugehörigkeit) um sie bei einem Senderscan zu pflegen.

Zerstöre ich die orginal (automatisch generierte) Senderdatenbank (services.xml und für die orginal bougetzugehörigkeit die bougets.xml) um meine eigene Sortierung und Grupierung zu ermöglichen kann die automatische Sendersuche ja nicht mehr funktionieren da entwder meine eigene Zusammenstellung zerstört wird oder die neuen Informationen nicht in die Datenbank aufgenommen werden können.

Soll heissen: Erstelle ich meine eigenen Bougets und sortiere meine Sender dort hinein kann beim Sendersuchlauf ja die Information "Dieser Sender gehört jetzt zum Bouget XY" nicht gespeichert werden ohne meine eigenen Bougets zu zerstören. Möchte ich dieses Sender jetzt anhand des orginal Bougets finden geht das nicht das diese Information nicht mehr vorhanden ist.

zor hat geschrieben:
Wäre es nicht sehr viel einfacher, Playtzsparender und schneller diese Sachen in irgendeinem Binären Format zu speicher?
ich denke zum einen werden die listen vom webinterface geparst und zum anderen ist die datei dadurch in einem format, welches man auf den ersten blick versteht!

Wo ist das Problem wenn das Webinterface ein Binäres Format parst? Software ist es ja egal ob etwas auf den ersten Blick versteht oder nicht da sie eh nichts versteht.

Und warum muß man das auf den ersten Blick verstehen? AFAIK ist XML ein Datenaustauschformat und kein Datenbankformat.
Und bei einem guten Receiver sollte es nicht notwendig sein in irgendwelchen Datenbanken mit einem Editor rumzumachen. Sollte es dennoch gewunscht sein kann man ja ein Programm anbieten welches die Senderliste nach XML exportiert. Und dann auch eine XML Senderliste importiert.

Mir ist natürlich bewust das das eine Menge mehr Programmieraufwand bedeuten würde und es deshalb bei den XML Listen bleiben wird.
Aber ich verstehe wirklich nicht warum ausser mir keiner der der Meinung ist ein Binäres Format zur Speicherung der Listen wäre besser.
Das weist natürlich stark daruf hin das meine Meinung einfach falsch ist. Aber warum höre ich dann keine Argumente die mich überzeugen meine Meinung zu ändern? ;-)

Warum ich das alles überhaupt anspreche: IMHO sollte man bevor jetzt an den XMLs rumgebastelt wird erstmal ein Ideal finden. Inwieweit du dich dem bei der Umsetzung dann annäherst bleibt dann natürlich immer noch dir überlassen.

Und da du offensichtlich nicht viel von Favoriten hälst ist es IMHO auch schon mal wichtig zu erwähnen das andere sowas gut und nützlich finden.
Evtl. magst du sowas denn ja trotzdem berücksichtigen so das wir evtl. mal richtige Favoriten bekommen und sie nicht wieder nur als Hack dort reinrutschen.

cu
usul

Beitrag von **Houdini** » Dienstag 18. Juli 2006, 13:51

Warum dann aber XML? Wäre es nicht sehr viel einfacher, Playtzsparender und schneller diese Sachen in irgendeinem Binären Format zu speicher?

Man kann ja trotzdem eine Lib einbauen die das private Senderlisten Format nach irgendeinem XML wandelt und umgekehrt (so das z.B. ein Services.xml download über das Web Interface "on the Fly" nach XML konvertiert). So das man (z.B. ein Bougeteditor) trotzdem mit XML Dateien arbeiten könnte (als einheitliche Schnittstelle) aber das Speichern privat in irgendeinem Binärformat stattfindet.

Genau meine Meinung

Beitrag von **zor** » Dienstag 18. Juli 2006, 14:39

@usul1

Die sind in der bougets.xml. Und diese gehört ja untrennbar zur services.xml (Die bougets.xml enthält ja als einzige Information zu welchem Bouget ein Service gehört). Wie untrennbar die verbunden sind zeigt sich ja wenn man die bougets.xml editiert. Dann funktioniert das ganze System ja nicht mehr richtig (z.B. springt Neutrino bei Sendern die in zwei Bougets sind nach einem reload der Senderlisten auf den falschen Sendeplatz).

sicher gehören die zusammen. aber wenn man nun zu jedem eintrag in der services.xml, neben die sid reinschreibt, zb: bouquet="sport" oder wie auch immer, dann ist das chaotisch verteilt. besser ist's wie in bouquets gelöst, dass man sport hat und dann alle sender dazu...
das mit dem springen bei zwei gleichen sender in den bouquets kann man sicher auch durch die .zapit lösen. zb last_bouqet= oder so..

Soll heissen: Erstelle ich meine eigenen Bougets und sortiere meine Sender dort hinein kann beim Sendersuchlauf ja die Information "Dieser Sender gehört jetzt zum Bouget XY" nicht gespeichert werden ohne meine eigenen Bougets zu zerstören. Möchte ich dieses Sender jetzt anhand des orginal Bougets finden geht das nicht das diese Information nicht mehr vorhanden ist.

also bei mir funktioniert die option "bouquets nicht verändern" hervorragend! nach einem scan ist die bouquets.xml wie zuvor und die neuen sender im bouquet andere..

Mir ist natürlich bewust das das eine Menge mehr Programmieraufwand bedeuten würde und es deshalb bei den XML Listen bleiben wird.

vorhandenes abzuändern ist sicher am leichtesten zu realisieren..

Und da du offensichtlich nicht viel von Favoriten hälst ist es IMHO auch schon mal wichtig zu erwähnen das andere sowas gut und nützlich finden.

ich halte andere meinungen für sehr wichtig - nur so kann man das beste daraus machen...

@houdini

speichern binär, arbeiten mit xml? wenn's um den platz geht so gibts auch tar.gz

gruss zor

Beitrag von **usul1** » Dienstag 18. Juli 2006, 16:05

zor hat geschrieben: sicher gehören die zusammen. aber wenn man nun zu jedem eintrag in der services.xml, neben die sid reinschreibt, zb: bouquet="sport"

Der Witz ist ja gerade das ich der Meinung bin ein Bouget "sport" hat in der Senderliste nichts verloren. Dieses gehört IMHO in die Favoritenliste. In dieser stehen Bougets und unter denen die Verweise auf die Sender in der Senderliste. Dann noch ein Flag ob man den Orginalnamen möchte oder ein eigener Name gewünscht ist.
Dort (in der Senderliste) gehören die Bouget Namen rein die der Anbieter mitsendet. z.B. "RTL World" oder "SAT1". Oder was auch immer für Namen mitgeschickt werden.

Wenn ich einen Forum lese das RTL einen neuen Sender aufgeschaltet hat ist es IMHO am einfachsten in das "RTL World" Bouget zu schauen um den Sender zu finden. Das bedingt aber das bei diesem neuen Sender auch die Information gespeichert wird das dieser Sender zum Anbieter "RTL World" gehört.

Und so wie ich dich verstehe beist sich der Vorschlag einer Favorietenliste (als seperate Datenbank) auch nicht mit deiner Art mit der Senderliste umzugehen. Dann ob du nun die Senderliste nach deinen Wünschen änderst oder ob du alle Sender auf einen Rutsch in die Favoritenliste kopierst (diese Möglichkeit sollte IMHO vorhanden sein) und dann halt die Favoritenliste nach deinen Wünschen bearbeitest dürfte ja egal sein, oder?
Dann evtl. noch die _Option_ neue Sender automatisch in die Favorietenliste zu Kopieren (meinetwegen in ein Bouget namens "andere"

und es besteht für diejenigen die die jetzige Lösung bevorzugen kein Unterschied.

BTW: Was ich auch noch schön fände wäre wenn zu jedem Sender in der Senderliste das Eintragdatum mit gespeichert würde. Dann könnte "Software" auf Wunsch eine Liste mit den neuen Sendern in cronologischer Reihenfolge zeigen.
Im Moment muß man ja darauf achten das Bouget "Neue Sender" nicht zu verpassen. Beim nächten Start liegen die neuen Sender ja schon in der langen "Andere" Liste und verschwinden darin.
(Auch wenn das keiner Programmiert konnte man das Feld "Eintragsdatum" ja jetzt trotzdem schonmal vorsehen)

zor hat geschrieben: oder wie auch immer, dann ist das chaotisch verteilt. besser ist's wie in bouquets gelöst, dass man sport hat und dann alle sender dazu...

Die Liste wird doch eh von zapit eingelesen. Da ist es doch egal ob es in der Datei nicht zusammensteht. Zapit kann ja intern (oder tut es schon) eine Bougetliste führen ind der die Sender zusammengefasst sind.
Damit zapit weis das die Sender "RTL" und "RTL2" in das Bouget "RTL World" gehört ist es ja nicht zwingend notwendig das diese in der Datei zusammen unter dem Begriff "RTL World" gruppiert sind.

zor hat geschrieben: also bei mir funktioniert die option "bouquets nicht verändern" hervorragend! nach einem scan ist die bouquets.xml wie zuvor und die neuen sender im bouquet andere..

Eben, das sehe ich als Problem. Ich möchte nicht eine riesenlange Liste unter dem Bouget "Andere" sondern ich möchte die Sender dort finden wo ich sie erwarte.
Desweiteren werden in der Einstellung "Bougets nicht ändern" nicht mehr existierende Bougets nicht gelöscht.
Wenn z.B. Digital+ sich entschließt ihre Sender wieder unter dem Anbieternamen "Digital+" zu senden habe ich nach dem Sendersuchlauf trotzdem noch die Bougets "TQ1", "TQ2" usw.

zor hat geschrieben: ich halte andere meinungen für sehr wichtig - nur so kann man das beste daraus machen...

War auch nicht als Kritik (in derart das ich dir vorwerfe an anderen Meinungen nicht interessiert zu sein) gedacht (falls jemand das so verstanden haben sollte) sondern eher als Rechtfertigung warum ich als nicht Dev dazu meinen Senf abgebe. (Nur für den Fall das ich mich missverständlich ausgedrückt habe)

zor hat geschrieben: speichern binär, arbeiten mit xml?

Eben nicht "arbeiten mit XML". XML kommt DANN nur noch ins Spiel wenn der Benutzer einen export der Senderlisten wünscht (Und sie z.B. am PC mit einem Editor zu bearbeiten).Im Normalbetrieb ist es IMHO völlig überflüssig dort was mit XML zu machen.

zor hat geschrieben: wenn's um den platz geht so gibts auch tar.gz

Erst die Informationen aufblähen um sie in einem Menschlesbaren Format mit Tags im Klartext zu speichern und dann packen? ;-)

Warum dann nicht gleich so schreiben das überflüssige Informationen nicht geschrieben werden?

BTW: Das XML hat doch eh nur ein kurzes Leben. Beim Start der Box liest zapit die Sendelliste. In zapit selber ist das XML dann schon nicht mehr existent. Bei Änderungen schreibt dann zapit die XML Liste aber dann liegt sie auch nur im Dateisystem.
Das Web Interface liest sie auch nur bei Bedarf. Aber das dürfte ja egal sein ob es die Liste im XML oder in einem Binären Format liest.

Also sorum gefragt: Was hat man davon die Liste als XML zu speichern?

Der Punkt ist ja das mit den Dateien selber nicht als Datenbank gearbeitet wird sondern das sie nur die Informationen speichern sollen wenn das Gerät aus ist.
Die Informationen werden dann ja eh in den Programm selber verwaltet. Und dort ist ja XML nicht im Spiel.

cu
usul

Beitrag von **zor** » Mittwoch 19. Juli 2006, 17:43

@usul1 @all

da es hier offenbar keine xml-senderlisten freunde gibt habe ich mir ein kompaktes format überlegt, welches ich hier mal vorschlage...

die services:

Code: Alles auswählen

sat{
   satpos:satname{
      freq:tsid:onid:srate:pol:fec:nit:action{
         sid:type:name:provider:action{
            name=:provider=:type=:sid=:audio=:txt=
         }
         sid:type:name:provider:action{
            name=:provider=:type=:sid=:audio=:txt=
         }
         sid:type:name:provider:action{
            name=:provider=:type=:sid=:audio=:txt=
         }
      }
   }
}

cable{
   cablepos:cablename{
      freq:tsid:onid:srate:pol:fec:inv:mod:nit:action{
         sid:type:name:provider:action{
            name=:provider=:type=:sid=:audio=:txt=
         }
         sid:type:name:provider:action{
            name=:provider=:type=:sid=:audio=:txt=
         }
         sid:type:name:provider:action{
            name=:provider=:type=:sid=:audio=:txt=
         }
      }
   }
}

terrestrial{
}

ich denke sowas ist minimalistisch und sollte alles abdecken was so gewünscht ist. zu jeder sid kann man alles ändern was man möchte. die provider wären nun dabei und durch das klammer auf/klammer zu spart man sich viele wiederholungen. das action ist das erwähnte vom beginn des treads!
ich weiß nicht, obs im kabel eine nit gibt, aber ich habs mal reingemacht ;-)
setzt werden sich viele fragen was die cablepos ist! nun, da könnte man die längen und breitengrade des firmensitzes (des anbieters) eintragen und hätte somit eine eindeutige kennung!
weiters wäre diseqc ausgegliedert und das ganze sehr platzsparend. man hat noch dazu die möglichkeit das ganze nach providern sortieren zu lassen!

und nun dazu eine favourites:

Code: Alles auswählen

sat{
   name{
      satpos:tsid:onid:sid
      satpos:tsid:onid:sid
      satpos:tsid:onid:sid
      satpos:tsid:onid:sid
   }
   name{
      satpos:tsid:onid:sid
      satpos:tsid:onid:sid
      satpos:tsid:onid:sid
      satpos:tsid:onid:sid
   }
}

cable{
   name{
      cablepos:tsid:onid:sid
      cablepos:tsid:onid:sid
      cablepos:tsid:onid:sid
      cablepos:tsid:onid:sid
   }
}

terrestrial{
}

schlicht und einfach

nun mal eure meinung dazu! was wird vermisst, was passt?

gruss zor

Beitrag von **Houdini** » Mittwoch 19. Juli 2006, 17:55

ich denke es macht keinen Sinn die XML Variante durch eine anders proprietäres Format zu ersetzen.
XML solte als Format für den Import/Export der Sendelisten benutzt werden, das interne Fileformat sollte ein "maschinenlesbares" binäres sein (wodrin dann durchaus die oben angegebenen Infos stecken können)

Houdini

Beitrag von **zor** » Mittwoch 19. Juli 2006, 19:17

@houdini

ich verstehe immer noch nicht den gedanken zu den "doppelten" senderlisten. wenn man sich auf ein einfaches format einigt (wie zb dem soeben vorgeschlagenem), dann kann man das ja auch importieren und exportieren - wozu dann noch xml? enigma etwa hat ja auch nur ein binäres format...
das webinterface kann dann das binäre format verwenden (parsen). die editoren helfen dann senderlisten zu erstellen..

gruss zor

Beitrag von **zor** » Sonntag 23. Juli 2006, 00:35

es würde mich freuen, wenn wir hier das zu ende diskutieren, damit das problem gelöst wird!

beste grüße zor

Beitrag von **usul1** » Sonntag 23. Juli 2006, 01:09

zor hat geschrieben:es würde mich freuen, wenn wir hier das zu ende diskutieren, damit das problem gelöst wird!

Sollte man das nicht erstmal einwenig wirken lassen und evtl. noch warten ob sich andere mit Meinungen melden?

Wobei es mich wirklich wundert das sich nicht mehr hieran beteidigen.

cu
usul

Beitrag von **Nico 77** » Sonntag 23. Juli 2006, 11:17

usul1 hat geschrieben:Sollte man das nicht erstmal einwenig wirken lassen und evtl. noch warten ob sich andere mit Meinungen melden?

cu
usul

Ich bin absolut dagegen die satellite.xml, cables.xml usw mit den Settings zu vereinenen.
Erstens müssten die Settings dann im /var/ sitzen was unheimlich Platz braucht bei einer großen Sat und Kabel.xml.
Meine Sat- und Kabellisten haben eine größe von ca.600kb und wird ständig mehr.
Wie soll ich die bitteschön im /var/ unterbringen?
Im Squashfs brauchen sie letztendlich ca.30kb wenn überhaupt.
Zweitens ist Gefahr viel zu groß das die Senderlisten zuschossen werden und man wieder auf die Box muss wo normal nur eine neue Kanalsuche machen bräuchte.

Ein Image darf nicht erst durch das einspielen von Settings funktionieren wie in den komischen Boards zur Verdummung der User provagiert wird, wo die Leute mittlerweile nach Settings betteln weil sie nicht wissen was eine Kanalsuche ist geschweige denn wie sie funktioniert.
Es muss durch eine Kanalsuche die komplette Funktion gegeben sein.

Wenn es um die größe des XML Format geht sollte man vielleicht mal bei ru-dbox anfragen nach dem NeutrinoDream Format.
Ansonsten wäre ich für das Enigma Format, Sat und Kabel.xml weiterhin getrennt von den Settings, das Settingformat ist kleiner als bei Neutrino und wäre dann zusätzlich noch kompatible zu Enigma.

Beitrag von **zor** » Dienstag 25. Juli 2006, 02:07

@nico77

Ich bin absolut dagegen die satellite.xml, cables.xml usw mit den Settings zu vereinenen.
Erstens müssten die Settings dann im /var/ sitzen was unheimlich Platz braucht bei einer großen Sat und Kabel.xml.

die settings so wie ich sie zuletzt vorgeschlagen habe sind wirklich sehr klein. ich meine minimal. zähle doch schon alleine mal die wiederholungen weg (zb channel oder service_id= oder name= oder service_type=) welche für xml typisch sind...

Meine Sat- und Kabellisten haben eine größe von ca.600kb und wird ständig mehr.
Wie soll ich die bitteschön im /var/ unterbringen?

meine satellites.xml hat 147kb und hat alle satelliten und (aktiven!)transponder von -45Â° bis 45Â° drinnen. durch abänderung des formats auf das von mir vorgeschlagene käme man auf ein drittel oder viertel der größe (mal abgeschätzt). also sagen wir mal 45kb. komprimiere ich das mit tar.gz dann komme ich auf 5kb!!!! 5kb lassen sich leicht im squashfs unterbringen. man hat so also mal ein "backup"

mal angenommen jemand bootet ein yadi zum ersten mal, so wird das nach /var geholt. okay, sind dann wieder 45kb. durch einen suchlauf auf astra würde sich die dateigröße (ich schätze) maximal verdoppeln. bei 2 sats verdreifachen etc.

ich rechne vor:
kompaktes senderlistenformat:
1sat
100kb (services+myservices+satellites vereint)
2sat
150kb (services+myservices+satellites vereint)

in meinem image:
1sat
80kb (services.xml) + 20kb (myservices.xml) + 147kb (full_satellites.xml) = 250kb
2sat
160kb (services.xml) + 40kb (myservices.xml) + 147kb (full_satellites.xml) = 350kb

somit kann man überschlagsmäßig sagen, dass mit xml pro satellit doppelt so viel platz benötigt wird (das eine summiert jeweils 50, das andere jeweils 100)..
.."schuld" sind klarerweise die vielen wiederholungen bei xml

Zweitens ist Gefahr viel zu groß das die Senderlisten zuschossen werden und man wieder auf die Box muss wo normal nur eine neue Kanalsuche machen bräuchte.

dadurch, dass die 5kb tar.gz im squashfs liegen braucht man nicht (etwa per ftp) auf die box. hat der sendersuchlauf mist gebaut so hat man ja ein "backup"

Ein Image darf nicht erst durch das einspielen von Settings funktionieren wie in den komischen Boards zur Verdummung der User provagiert wird, wo die Leute mittlerweile nach Settings betteln weil sie nicht wissen was eine Kanalsuche ist geschweige denn wie sie funktioniert.
Es muss durch eine Kanalsuche die komplette Funktion gegeben sein.

die im squashfs liegende datei würde keine sender beinhalten, sondern nur satelliten und transponder (so wie die satellites.xml). die sender würden erst durch einen suchlauf im /var eingefügt werden...

Wenn es um die größe des XML Format geht sollte man vielleicht mal bei ru-dbox anfragen nach dem NeutrinoDream Format.

das neutrino-dream xml format unterscheidet sich minimal von dem der dbox...

Ansonsten wäre ich für das Enigma Format, Sat und Kabel.xml weiterhin getrennt von den Settings, das Settingformat ist kleiner als bei Neutrino und wäre dann zusätzlich noch kompatible zu Enigma.

ich sehe meinen vorschlag gegenüber enigma als geschickter an und führe hier auch gerne die gründe an. die kompatibilität zu enigma selbst wäre natürlich positiv hervorzuheben!

beste grüße zor

Beitrag von **Nico 77** » Dienstag 25. Juli 2006, 16:00

Mein Satellite geht von 58Â°West bis 88Â° Ost und ist somit größer.

Wenn du nur noch eine Datei haben willst passt das aber nicht das du ein .tar File mit Sat/Kabeldaten in den root Bereich haust.
Dann machst du ja gleiche wie jetzt auch, die Sat und Kabel xml sind normal Standart im root und werden dort von squashfs gepackt.
Zusätzlich komprimiert squashfs xml besser wie tar im Image und ein zusätzliches entpacken kostet wieder Resourcen was nicht nötig ist.

Die Sat/Kabel xml müssen in jedem Fall getrennt von den Settings sein um durch Fehler auf der sicheren Seite sein zu können und dein tar ist wie gesagt das gleiche wie jetzt nur umständlicher.
Zusätzlich würde die aktuelle Kompatiblität zu Enigma verloren gehen, weil du ein zusätzliches tar File willst, man die Sat und cables.xml aber trotzdem für Enigma braucht.
Somit hingt es auch hier mit dem Platz da man nun 3 zusätzliche Dateien mitschleppen müssten und normal nur 2(sat und cables.xml).

Das ru-dream Format bietet kompatiblität zu den Sat/Kabel.xml's und genau macht genau das was du haben möchtest, nämlich sparsame Settings.
Durch Abkürzungen der einzelnen Werte komme ich mit Sicherheit auf kleiner Settings wie als wenn ich jedesmal die satellite.xml Daten mit reinschreibe.

Aber hänge dein neues Format mit Astra only mal an, ich vergleiche das dann mit dem ru-format bzw auch mit Enigma.
Würde mich natürlich gerne eines besseren Belehren lassen.

Beitrag von **Barf** » Dienstag 25. Juli 2006, 21:27

Hier ist ein proof-of-concept-Typ Patch, sodass services.xml direkt komprimiert (gzipped) gelesen und geschrieben wird. Es wird also nicht einen Datei geschrieben, und danach komprimiert, sondern direkt (in einer Pipe) im Speicher komprimiert. popen statt fopen. Ist proof-of-concept und nicht vollständig; Nirvanas currentservices-merging wird z.Z. nicht unterstützt. Es wäre auch möglich, bouquets.xml so zu behandeln.

Dadurch wird die services-Files kaum größer als ein optimiertes Binärformat.

zors vorgeschlagene Format hat den Nachteil von XML (deutlich größer und ineffizienter als binär), hat aber nicht die Vorteile von XML (insbesonders: ein großer Anzahl werkzeuge (parsers, transformationssprachen, formatierungswerkzeuge, etc) existiert, wohl specifiziert (z.B. encoding), validierung beim Parsen möglich).

die drei Dateien satellites/cables.xml, services.xmk, myservices.xml sind dadurch motiviert, weil die Daten drin unterschiedliche "Eigentümer" haben: satellites/cables.xml: Maintainer/User, services.xml: Das System, wird bei scan neu geschrieben; myservices.xml: der User. Es is möglich, dass "Eigentümerproblem" anders zu lösen; fordert aber etwas Coding!

kann man nicht für die neue vereinigte satellites.xml den user als eigentümer setzten?

Ich spreche über Erzeuger der Informationen, nicht über Dateieigentümer (ist immer root beim Tuxbox). Hier wirfst du wieder eine gute Lösung (Dateien die den Erzeuger entsprechen) ersatzlos weg.

da ich bisher kein programm für linux kennengelernt habe ist die datei selbst benutzerschnittstelle für mich...

Die normale Benutzerschnittstelle zu den Datenbanken ist der Neutrino Editor und die Web-Interface. So schlecht ist z.B. yweb nicht....

Ein Bouquet ist (per Definition) eine Teilmenge der Services. Die Bouquots bilden nicht notwendigerweise eine Partition der Services. Ein Service kann null, ein, oder mehrere Bouquets zugehören. Also ist es nicht machbar (aus prinzipielle Grunden!) die Bouquetliste mit Attribute in services zu ersetsen.

Beitrag von **zor** » Dienstag 25. Juli 2006, 22:15

edit:
doppelpost
edit

Beitrag von **zor** » Dienstag 25. Juli 2006, 22:39

@nico77

Mein Satellite geht von 58Â°West bis 88Â° Ost und ist somit größer.

okay! du bist einer der wenigen user, welche wirklich einen riesenbereich abdecken!

Wenn du nur noch eine Datei haben willst passt das aber nicht das du ein .tar File mit Sat/Kabeldaten in den root Bereich haust.
Dann machst du ja gleiche wie jetzt auch, die Sat und Kabel xml sind normal Standart im root und werden dort von squashfs gepackt.
Zusätzlich komprimiert squashfs xml besser wie tar im Image und ein zusätzliches entpacken kostet wieder Resourcen was nicht nötig ist.

wenn squashfs besser komprimiert als tar, dann kann man das ja unkomprimiert in den root-bereich reinmachen. für den sehr großen bereich von -45Â° bis +45Â° würden dann trotzdem die 5kb wohl nicht unterboten werden. für deine megasatellites in meinem kompakten format würden dann halt 10kb anfallen - immer noch ein eck kleiner als deine satellites.xml (mit 600kb) welche im squashfs dann wohl 40kb haben würde..

Die Sat/Kabel xml müssen in jedem Fall getrennt von den Settings sein um durch Fehler auf der sicheren Seite sein zu können und dein tar ist wie gesagt das gleiche wie jetzt nur umständlicher.

so wie jetzt die cables.xml und die satellites.xml als backup im root liegen würde meine services ebenfalls im root liegen. nur halt weniger platz wegnehmen.

Zusätzlich würde die aktuelle Kompatiblität zu Enigma verloren gehen, weil du ein zusätzliches tar File willst, man die Sat und cables.xml aber trotzdem für Enigma braucht.

die yadis haben schon seit längerem nur eine gui zu bieten. die neutrinouser hätten halt die services im root, die enigma user halt die cables.xml und satellites.xml

Das ru-dream Format bietet kompatiblität zu den Sat/Kabel.xml's und genau macht genau das was du haben möchtest, nämlich sparsame Settings.
Durch Abkürzungen der einzelnen Werte komme ich mit Sicherheit auf kleiner Settings wie als wenn ich jedesmal die satellite.xml Daten mit reinschreibe.

*) die settings werden durch das ru-format kleiner, aber sicher nicht so klein wie bei mir!
*) mein kompaktes format hat noch andere vorteile außer der größe!
>aufnahme des providers
>ersetzen und hinzufügen jeder menge werte direkt bei der sid
>die action bietet mehr möglichkeiten als die action in den myservices
>nit kennung direkt beim transpondereintrag

Aber hänge dein neues Format mit Astra only mal an, ich vergleiche das dann mit dem ru-format bzw auch mit Enigma.
Würde mich natürlich gerne eines besseren Belehren lassen

werde mir die mühe machen die unterschiedlichen formate nebeneinander zu vergleichen und dann einen link reinmachen! dauer aber ein wenig...

@barf
deine idee das format komprimiert auszulesen ist eine sehr gute idee! eine änderung des formats hätte aber auch noch andere vorteile wie ich nico77 aufgezeigt habe..

mein zuletzt vorgeschlagenes format hat nichts mehr mit xml am hut. sicher fallen viele xml-werkzeuge weg, aber funktionen zu schreiben, welche das format auf gültigkeit überprüfen sollte nicht soo schwierig sein. ich würde mich gerne bei sowas beteiligen..

da ich weiters einen guten kontakt zu downwards (bouquetwizard) habe sollte auch relativ schnell ein programm existieren, welches das format beherrscht..

Dateien die den Erzeuger entsprechen

ich erkenne nicht den programmiertechnischen hintergrund bzw. vorteil

satellites/cables.xml: Maintainer/User >> kann so bleiben für mein kompaktes format. gehe davon aus, dass du eine satellites.xm im /var meinst, da die im root ja nicht veränderbar ist.

services.xml: Das System, wird bei scan neu geschrieben
myservices.xml: der User

so wie der user bei der satellites.xml (im /var) eingreifen kann, so kann der user halt bei den neuen services eingreifen. so oder so - ganz gleich wer der erzeuger der information ist. lösche ich die services.xml, so ist sie futsch...

Ein Bouquet ist (per Definition) eine Teilmenge der Services. Die Bouquots bilden nicht notwendigerweise eine Partition der Services. Ein Service kann null, ein, oder mehrere Bouquets zugehören. Also ist es nicht machbar (aus prinzipielle Grunden!) die Bouquetliste mit Attribute in services zu ersetsen.

das ganze war nur eine idee, welche aber nicht umgesetzt werden soll. die bouquets und favoriten sind extra.

gruss zor

Beitrag von **usul1** » Dienstag 25. Juli 2006, 23:38

Barf hat geschrieben:Ein Bouquet ist (per Definition) eine Teilmenge der Services. Die Bouquots bilden nicht notwendigerweise eine Partition der Services. Ein Service kann null, ein, oder mehrere Bouquets zugehören. Also ist es nicht machbar (aus prinzipielle Grunden!) die Bouquetliste mit Attribute in services zu ersetsen.

Sowas soll mit dem hochgelobten XML nicht gehen? (Oder was meinst du mit prinzipiellen Gründen?)

Code: Alles auswählen

<channel service_id="768e" name="TAQUILLA 1" service_type="01">
  <bouget name="Favoriten"/>
  <bouget name="Nachrichten"/>
  <bouget name="Wichtig"/>
</channel>

(Nicht schlagen wenn dieses Beispiel blödsinn ist, bin XML Anfänger)

Wobei wir erstmal festlegen sollten was Bougets überhaupt sind. Sind es die Zugehörigkeiten die vom Sender mitgeschickt werden? Oder ist es die Grupierung die der Nutzer möchte?

Beides zusammenmischen halte ich immer noch für Blödsinn.

cu
usul

Beitrag von **Houdini** » Dienstag 25. Juli 2006, 23:40

sowohl squashfs als auch cramfs als auch jffs2 sind "komprimierende Filesysteme",
d.h. die Files werden schon gepackt im Flash abgespeichert.
Eine zusätzliche Komprimierung bringt also außer weiterem Zeitverlust durch das hin- und herkomprimieren nix!

Houdini