vorschlag zu den xml-senderlisten

[Nico 77]

@nico77

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

gruss zor

Wenn du die .xml aber nochmal packen willst und jedesmal entpacken willst das kostet zusätzliche verschwendete Leistung, die Squashfskomprimierung reicht dafür völlig. Im root was extra zu packen außer dem Kernel halte ich nicht für sinnvoll und würde einfach keine Vorteile bringen außer zusätzliche Leistungseinbußen in der Zeit wo die Datei entpackt werden muss.

Yadi ist nicht CVS und da kann man beides Prima nutzen.
Zusätzlich würde ein anderes Sat/Kabelformat zusätzliche Arbeit verursachen für Neutrino/Enigma Mixuser.

Ich finde deine Idee ja auch sehr gut die Settings zu verkleinern.
In welcher Form ist mir auch egal, aber sat/kabel.xml in jedenfall extra weiterhin kompatibel und das auch für die Zukunft siehe Enigma2 und Neutrino2.


Ein echter Fortschritt wäre für mich das wenn die sat/kabel.xml's wahlweise aus dem /var/ und root geladen werden könnten wie bei Enigma.

[zor]

@all

zuallererst möchte ich euch darauf aufmerksam machen, dass ich sowas wie eine zusammenfassung erstellt habe. dabei vergleiche ich die formate von neutrino, neutrino-ru und enigma mit dem meinen vorgeschlagenen.
seht's euch einfach mal an

http://rapidshare.de/files/27030390/neu ... 1.txt.html

einfach auf free klicken und dann den code eintippen..

@usul1

ich meine auch, dass eine zuordnung zu bestimmten gruppen direkt in der senderliste möglich wäre (du hast das ja angedeutet), halte es aber nicht für sinnvoll...

@houdini

alles klar! ich werd's nicht packen!

@nico77

Squashfskomprimierung reicht dafür völlig

ich stimme dir zu - du hast mich überzeugt (gemeinsam mit houdini)

..sat/kabel.xml in jedenfall extra weiterhin kompatibel..

das ganze wäre mal als experimenteller tree zu sehen...

Ein echter Fortschritt wäre für mich das wenn die sat/kabel.xml's wahlweise aus dem /var/ und root geladen werden könnten wie bei Enigma.

für gewöhnlich ist vom /var aus in den root bereich verlinkt. ein ersetzten des links durch eine datei löst dein problem

gruss zor

[usul1]

ich meine auch, dass eine zuordnung zu bestimmten gruppen direkt in der senderliste möglich wäre (du hast das ja angedeutet), halte es aber nicht für sinnvoll...

Macht dein Vorschlag nicht genau das?

Code: Alles auswählen

sat{
   0192:Astra 19.2E{
      10788000:041e:0001:22000000:0:5:1:none{
         768e:01:TAQUILLA 1:TQ1:none{
            name={TAQUILLA 1 {ESP}}:provider={TAQUILLA}
         }
         ...
      }
   }
}

Hier wird das Bouget (so wie Neutrino Bougets versteht) mit in die Senderliste genommen.

Wie willst du die vom Nutzer erstellten Bouget (also die Favoritenlisten) behandlen?
Das jetzige System auf deine Senderliste übertragen würde ja auf sowas in der Art hinauslaufen:
provider={TAQUILLA:Favoriten:Pay-TV}
(Und das ist ja exakt das selbe was ich mit dem XML Beispiel angedeutet habe)

für den einen premiere feed, welcher kein epg anzeigt könnte man eine option epg=hex-wert mitgeben, damit das wieder korrekt angezeigt wird

Du meinst dem Sectionsd sagen nimm für diesen Sender den EPG von XYZ?
So das man für RTL Schweiz evtl. den EPG von RTL Deutschland setzen könnte? Das wäre ne tolle Idee und käme auch meinem Feature Request hier ( http://forum.tuxbox-cvs.sourceforge.net ... highlight= ) entgegen indem man auf diese Weise einen gesendeten EPG unterdrücken könnte (auf einen nichtvorhandenen setzen).

cu
usul

[zor]

Hier wird das Bouget (so wie Neutrino Bougets versteht) mit in die Senderliste genommen.

unter neutrino sind die bouquets individuell zusammengestellte gruppen, unter enigma sind bouquets senderlisten geordnet nach providern. wie auch immer, das individuelle lasse ich in den zor-services weg...

generell sehe ich 2 möglichkeiten der senderordnung:

a) die zusammenstellung in gruppen nach persönlicher wahl und mit persönlichen gruppennamen
b) die automatisierte zusammenstellung nach bestimmten mustern mit vorhandenen daten

ganz gleich wie ich das mache - die persönlichen gruppennamen wären nicht in der zor-services, also kein:

Code: Alles auswählen

sat{
   0192:Astra 19.2E{
      10788000:041e:0001:22000000:0:5:1:none{
         768e:01:TAQUILLA 1:TQ1:none{
            name={TAQUILLA 1 {ESP}}:provider={TAQUILLA} pers={meine spanischen sender}
         }
         ...
      }
   }
}

nimm für diesen Sender den EPG von XYZ

ganz genau! für RTL Schweiz den epg von RTL Deutschland
für den einen premiere feed - den epg vom transponder wo er gesendet wird
etc.
das ganze wäre dann aber kein hex-wert, wie von mit im dokument beschrieben, sondern ein verweis auf den sender, wo sich das epg befindet, zb:

Code: Alles auswählen

epg=satpos_tsid_onid_sid

gruss zor

[usul1]

generell sehe ich 2 möglichkeiten der senderordnung:

a) die zusammenstellung in gruppen nach persönlicher wahl und mit persönlichen gruppennamen
b) die automatisierte zusammenstellung nach bestimmten mustern mit vorhandenen daten

Aber nicht als ODER. Es muß IMHO beides Implementiert sein.

ganz gleich wie ich das mache - die persönlichen gruppennamen wären nicht in der zor-services, also kein:

Code: Alles auswählen

sat{
   0192:Astra 19.2E{
      10788000:041e:0001:22000000:0:5:1:none{
         768e:01:TAQUILLA 1:TQ1:none{
            name={TAQUILLA 1 {ESP}}:provider={TAQUILLA} pers={meine spanischen sender}
         }
         ...
      }
   }
}

Das wäre auch meine Wunschvorstellung. Aber warum dann nicht auch die eigenen Sendernamen da rauslassen?

Dann wäre die eigene Zusammenstellung (Bougets und individuelle Namen) unabhängig von der Senderliste und könnte auch auf meheren Boxen (mit evtl. unterschiedlichen Senderlisten (eine empfängt z.B. mehere Satelieten)) portierbar.

ganz genau! für RTL Schweiz den epg von RTL Deutschland
für den einen premiere feed - den epg vom transponder wo er gesendet wird

Das fände ich wie schon gesagt klasse.

cu
usulr

[zor]

Aber nicht als ODER. Es muß IMHO beides Implementiert sein.

ja, beides

was die persönlichen gruppierungen anbelangt, so meine ich, dass das in der zor-services nichts verloren hat. die erstezungsfunktion
name= hat die funktion die namenskennung zu ersetzten, aber hauptsätzlich damit was vernünftiges dasteht. es gibt ja genug sender die da mist senden...
provider= damit man das selbst einem provider zuordnen kann. TQ1 und TQ2 etc. bei den spaniern ist doch mist. die gehören ja alle zu dem taquilla paket.

alles in allem sollen die sender vernünftig dargestellt werden, fehler der satellitenbetreiber und provider ausgebügelt werden. das ist alles.

wenn wer die sender nach seinen persönlichen vorstellungen ordnen will, so soll er das in einer anderen datei vornehmen..geht ja auch einfach ;-)


ich meine grundsätzlich wird im datenstrom auch die primäre sprachkennung und sekundäre sprachkennung gesendet und auch noch die zuordnung (entertainment, sports, dokumentation,...) und vieles mehr. nimmt man das alles zur services dazu, dann wird das um ein eck größer. ein:

Code: Alles auswählen

         sid:type:name:provider:lang1:lang2:sparte:action{
            name=:provider=:type=:sid=:lang1=:lang2=:sparte=:audio=:txt=:epg=
         } 

das würde beim automatiserten ordnen mehr möglichkeiten bieten ist aber komplexer...

gruss zor

[Barf]

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!

Soviel besser! Das Kernstück in meiner Aussage ist (und bleibt):

Das angebliche KO-Argument gegen XML (grosser Platzbedarf) ist nichtig.

Genau so nichtig halte ich die Vorteile von der Kompaktheit des re-Formats, und des zor-Formats.

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:
<channel service_id="768e" name="TAQUILLA 1" service_type="01">
<bouget name="Favoriten"/>
<bouget name="Nachrichten"/>
<bouget name="Wichtig"/>
</channel>

Dies sind Elemente, nicht Attribute. Siehe die XML-Spezifikation. Wichtiger nocht, die Bouquet-Information ist (a priori) keine technische Information, sondern Information über den Benutzer und sein Geschmack (z.B.). Deswegen ist es sinnvoll, dies von den Services zu trennen.

[usul1]

Dies sind Elemente, nicht Attribute. Siehe die XML-Spezifikation.

Naja, das sind Feinheiten. Ich wollte auch nur darauf hinaus das man das schon irgendwie ins XML bekommt ;-)

Wichtiger nocht, die Bouquet-Information ist (a priori) keine technische Information, sondern Information über den Benutzer und sein Geschmack (z.B.). Deswegen ist es sinnvoll, dies von den Services zu trennen.

Da sind wir einer Meinung. Deswegen der Vorschlag die Bougets die den persönlichen Geschmak betreffen (Favoriten) aus der Senderliste (also der Bougets.xml) zu schmeissen und dort nur die technischen Informationen (Die "Bougets" (in Neutrino Sprache)) mit in die Senderliste zu Packen.
Und ich hatte halt den Eindruck das du das jetzige System (System und user Bougets in eine Datei. Settings in die andere) bevorzugst.


Wie sollten und wirklich mal darauf einigen die Bougets die der User erstellt sprachlich von den Bougets die die Sender erstellen zu trennen ;-)
Leider vermischt halt Neutrino beides miteinander.

die erstezungsfunktion
name= hat die funktion die namenskennung zu ersetzten, aber hauptsätzlich damit was vernünftiges dasteht. es gibt ja genug sender die da mist senden...
provider= damit man das selbst einem provider zuordnen kann. TQ1 und TQ2 etc. bei den spaniern ist doch mist. die gehören ja alle zu dem taquilla paket.

Also die Sender Bougets und die Sender Namen beeinflussen um die Fehler der Sender auszubügeln und nicht um sich damit seine eigenen favorisierten Sendernamen und Bougets zu basteln?
OK. Das klingt vernünftig.

Dann aber IMHO für die persönlichen Bedürfnisse zusätlich eigene Bougets (mehere Favoritenlisten) mit der Möglichkeit eigene Sendernamen einzutragen.

Dann dürfte IMHO alles Perfekt sein.

ich meine grundsätzlich wird im datenstrom auch die primäre sprachkennung und sekundäre sprachkennung gesendet und auch noch die zuordnung (entertainment, sports, dokumentation,...) und vieles mehr. nimmt man das alles zur services dazu, dann wird das um ein eck größer. ein:

[...]

das würde beim automatiserten ordnen mehr möglichkeiten bieten ist aber komplexer...

Viel wichtiger als das ordenen ist IMHO das dynamische Filtern.
Wenn ich jetzt einen Sender zu den Favoriten hinzufügen will habe ich eine Meterlange Liste mit Sendernamen. Dabei tauchen einige Sender doppelt auf und man weis nicht welcher der richtige ist.

Könnte man sich bei Sender hinzufügen eine Bougetliste anzeigen lassen (also die Gruppierungen die vom Sender kommen) wäre es einfacher den richtigen Sender schnell zu finden.
Oder mann könnte sich alle deutschen anzeigen lassen (Sofern die Sender da korekkte Infos mitsenden).
Oder alle neu dazugekommenen (Wenn das Eintragsdatum in die Senderliste dort auch noch gespeichert wird).

Bei den Technisat Receivern habe ich das so gesehen und es ist einfach klasse und es macht so richtig Spaß mal wieder neue Favoriten hinzuzufügen. Neutrino würde sowas auch sehr gut stehen.

cu
usul

[Nico 77]

für gewöhnlich ist vom /var aus in den root bereich verlinkt. ein ersetzten des links durch eine datei löst dein problem

gruss zor

Nein das löst das Problem leider nicht.
Standartlisten sollten aus Platzgründen sich im root befinden.
Wenn ich diese verlinke wird im /var/ sehr viel Platz verschwendet da nicht großartig komprimiert. Alles ja schonmal gesagt.

Es würde aber eine alternative Möglichkeit z.B. deshalb gebraucht weil im Kabel kein manueller Suchlauf möglich ist und User nicht die Möglichkeit haben die passende Symbolrate eingeben zu können fals diese in der Kabel.xml fehlt(andere Symraten hat z.b. englisches Kabel).

Das mit dem verlinken habe ich aber sowieso nie verstanden, warum schreibt ihr in der settings.h nicht direkt den korrekten link /var/bla/sat/kabel.xml anstatt zu verlinken?

[PT-1]

Das mit dem manuellen Suchen geht ja in englischen Images...

Werde da gleich mal nach den Diff's fragen dann kann man das ja in's CVS einbauen. Diffs

Reicht Frequenz und Symbolrate..?

Die Englaender haben ja auch noch die NetID

EDIT:

Hierja schon mal gepostet

[Nirvana]

Aus Sicht der automatischen Kanalsuche ist eine Zusammenlegung der satellites.xml und services.xml kontraproduktiv.
Die automatische Kanalsuche nutzt nämlich die satellites.xml nicht. Deshalb sind die Infos überflüssig und können in ihrer eigenen Datei bleiben.

Ebenso sollte die bouquets.xml bestehen bleiben.
Der Sinn ist klar: Jeder sollte dieselbe services.xml haben und die Struktur kommt durch die bouquets.xml.

Einzig die Satposition sollte nicht in den services stehen, wie bereits oben angemerkt.

[usul1]

Aus Sicht der automatischen Kanalsuche ist eine Zusammenlegung der satellites.xml und services.xml kontraproduktiv.
Die automatische Kanalsuche nutzt nämlich die satellites.xml nicht. Deshalb sind die Infos überflüssig und können in ihrer eigenen Datei bleiben.

Wenn man die Schnellsuche aktiviert wird die doch benutzt. Oder hat sich das geändert?

Ebenso sollte die bouquets.xml bestehen bleiben.
Der Sinn ist klar: Jeder sollte dieselbe services.xml haben und die Struktur kommt durch die bouquets.xml.

Nein. Zwei verschiedene Strukturen kommen durch die Bougets.xml und mischen sich da.

cu
usul

[zor]

hui da tut sich ja einiges ;-)

na dann packen wir's mal an:

@barf

okay, das platzargument zählt nicht! punkt!

im attachten dokument sind aber noch weitere punkte aufgezählt, welche das format attraktiv machen!

*) erweiterte action-befehle für transponder sowie sender
*) hinzufügen des providernamens
*) spidcache wie bei enigma
*) nit im transponder
...

die persönlichen einstellungen (bouquets bei neutrino, favoriten bei enigma) würden mit meinem konstrukt nicht verschmolzen werden

@usul1

das verändern des sendernamens oder des providernamens bleibt dir überlassen

das aufnehmen von sprachkennung und sparte und vielleicht auch verschlüsselungssystem ist vorstellbar. die möglichkeiten sind sehr vielfältig.

zb könnte man sortieren nach:
*) alle deutschsprachigen sportsender
*) alle sportsender
*) alle sender welche den premiere als provider haben
*) alle deutschsprachigen und englischsprachigen sender welche unverschlüsselt sind
*) alle cryptoworks-verschlüsselten französischen sender

bei auflistungen zu den verschlüsselungssystemen etwa könnte man schnell herausfinden welche sender zu seinem ci-modul passen

somit könnte man viele bereiche aus den persönlichen gruppen einfach definieren und muss nicht jeden sender einzeln einfügen..

@nico77

auch jffs2 ist ein komprimierendes dateisystem. das mit dem verlinken ist nicht schlecht. ist etwa die satellites.xml (im root) zu sehr veraltet (weil das image 1 jahr alt ist) so braucht man nur im /var eine satellites.xml dorthin setzten wo der link ist...

@nirvana

Die automatische Kanalsuche nutzt nämlich die satellites.xml nicht

ich denke du meinst den sectionsscan. bei einem gewöhnlichen suchlauf über alle transponder wird sehr wohl die satellites.xml verwendet

Ebenso sollte die bouquets.xml bestehen bleiben.
Der Sinn ist klar: Jeder sollte dieselbe services.xml haben und die Struktur kommt durch die bouquets.xml.

die bouquets bliebe ja bestehen - halt in einem neuen format
weiters hätte dann auch jeder die gleiche services - halt in einem neuen format

Einzig die Satposition sollte nicht in den services stehen, wie bereits oben angemerkt.

warum das? die satposition macht den satelliten eindeutig, der satname variiert von da zu da..außerdem wie nimmt man ohne satposition bezug auf einen satelliten?

gruss zor

[Nirvana]

Ich hasse den Begriff SectionsScan. Was kann man denn noch automatische Kanalsuche nennen? Heißt das ggf. denn zu recht so?

Zur Satposi:
Wie oben erwähnt möchte ich die Settings von einer Box zur anderen portieren können. Das geht aber nicht, wenn verschiedene Sats in einer services.xml sind. Es sollte also eine Datei geben in der steht:
diseqc0 = 0192E.xml
diseqc1 = 0130E.xml
...

Und dann kann 0192.xml von Box A nach Box B kopiert werden und es ist egal, ob da noch andere Sats vorhanden sind und an welchem diseqc der ggf. hängt.

[usul1]

Ich hasse den Begriff SectionsScan. Was kann man denn noch automatische Kanalsuche nennen? Heißt das ggf. denn zu recht so?

Hindergrund Suche? ;-)

Wie nennen das denn die Werbefuzzis bei den komerziellen Receivern?

Und dann kann 0192.xml von Box A nach Box B kopiert werden und es ist egal, ob da noch andere Sats vorhanden sind und an welchem diseqc der ggf. hängt.

Wenn wir schonmal dabei sind. Die Kanalliste (gerade bei getrennten Sats) kann auch auf ein Share was 24/7 läuft und dann kann eine Liste von allen Boxen im Haus gemeinsam genutzt werden.

BTW: Ich habe gerade meinen kostenlosen Webspace den es zu meinem Internetzugang dazugab per FTPFS ins Filesystem gemountet (Da speichert dann der Sectionsd sein EPG drauf und ein paar Plugins werden dann auch ausgelagert). Was spricht denn dagegen die Listen über das Internet gemeinsam zu nutzen. ;-)

cu
usul

[usul1]

Ich hasse den Begriff SectionsScan. Was kann man denn noch automatische Kanalsuche nennen? Heißt das ggf. denn zu recht so?

Hindergrund Suche? ;-)

Wie nennen das denn die Werbefuzzis bei den komerziellen Receivern?

Und dann kann 0192.xml von Box A nach Box B kopiert werden und es ist egal, ob da noch andere Sats vorhanden sind und an welchem diseqc der ggf. hängt.

Wenn wir schonmal dabei sind. Die Kanalliste (gerade bei getrennten Sats) kann auch auf ein Share was 24/7 läuft und dann kann eine Liste von allen Boxen im Haus gemeinsam genutzt werden.

BTW: Ich habe gerade meinen kostenlosen Webspace den es zu meinem Internetzugang dazugab per FTPFS ins Filesystem gemountet (Da speichert dann der Sectionsd sein EPG drauf und ein paar Plugins werden dann auch ausgelagert). Was spricht denn dagegen die Listen über das Internet gemeinsam zu nutzen. ;-)
Das wäre doch was für die Drehanlagenbesitzer. Bei jedem Boxenstart die top aktuelle Kanalliste vom öffentlichen Kanallisten FTP ;-)

cu
usul

[zor]

@nirvana

ja, das diseqc sollte raus. ob das nun einzelnen listen zugeteilt wird oder den satpositionen in einer großen liste ist dann egal..

könnte ja genauso gut so aussehen:

diseqc0=0192
diseqc1=-0123
...

@usul

bei satcodx kannst du dir die datenbanken zu jedem einzelnen sat saugen. mit geeigneten programmen kannst du das auch für neutrino konvertieren...

gruss zor

[Nirvana]

@nirvana

ja, das diseqc sollte raus. ob das nun einzelnen listen zugeteilt wird oder den satpositionen in einer großen liste ist dann egal..

Verstehe ich nicht. Wenn es eine Liste ist, kann ich die doch nicht kopieren. Ich will doch nicht alle Sats dieser Welt auf meiner Box.

[zor]

@nirvana

gedacht ist das so, dass die satelliten mit den transpondern im root liegen und beim ersten scan die benötigten rausgepickt werden und in die zor-services reingeschrieben werden (im var)
somit können in den zor-services im var zb 2 satelliten drinnen sein (sagen wir mal astra und hotbird). über die einstellung

diseqc0=192
diseqc1=130

in einer config (zb diseqc.conf) kann man dann zuordnen. die zor-services müssen dazu aber nicht aufgespalten werden..

@all

ich habe mir noch ein paar gedanken zu erweiterten senderlisten gemacht, weil man dadurch umfangreiche möglichkeiten hat!

so könnte das aussehen:

Code: Alles auswählen

sat{
   satpos:satname{
      freq:tsid:onid:srate:pol:fec:nit:action{
         sid:type:name:package:lang:genre:crypt:action{
            sid=:type=:name=:package=:lang=:genre=:crypt=:audio=:txt=:epg=
         }
         sid:type:name:package:lang:genre:crypt:action{
            sid=:type=:name=:package=:lang=:genre=:crypt=:audio=:txt=:epg=
         }
         sid:type:name:package:lang:genre:crypt:action{
            sid=:type=:name=:package=:lang=:genre=:crypt=:audio=:txt=:epg=
         }
         ...
      }
   }
}

wo lang, genre,crypt dazukämen. alleine schon die künftigen sortiermöglichkeiten wären mannigfaltig!

und ein bsp dazu:

Code: Alles auswählen

sat{
   0192:Astra 19.2E{
      10788000:041e:0001:22000000:0:5:1:none{
         768e:01:{TAQUILLA 1}:{TQ1}:{esp,org}:{Pay-per-View}:{seca}:none{
            name={TAQUILLA 1 {ESP}}:package={DIGITAL+}
         }
         ...
      }
   }
}

gruss zor

[usul1]

bei satcodx kannst du dir die datenbanken zu jedem einzelnen sat saugen. mit geeigneten programmen kannst du das auch für neutrino konvertieren...

Es war zwar nicht ganz ernst gemeint aber...
Das witzige ist man bräuchte garnichts programmieren (in Tuxbox) oder konvertieren um Sat Listen im Internet anzubieten.

Man legt eine auf einem FTP Server im Internet ab. Mountet den nach "/mnt/plugins/" und legt einen softlink von "/var/tuxbox/config/zapit/services.xml" nach "/mnt/plugins/services.xml".
Und schon greift die Box auf die services.xml Liste im Internet zu.


Und worauf ich praktisch hinauswollte: Wenn die Sateliten auf verschiedene Listen geteilt werden kann man die auf einen FTP/SMB/NFS Server im lokalen Netz ablegen und alle Boxen im lokalen Netz können auf diese Liste zugreifen.
D.h. nur noch eine Liste Pflegen für alle Boxen.

cu
usul

[zor]

ist zwar OT, aber gut:

Wenn die Sateliten auf verschiedene Listen geteilt werden

wenn du zentral eine große satellites.xml ablegst dann kann sich immer noch jede box ihre satelliten rausschneiden..

@all

ich hätte noch gerne ein paar meinungen zum format - aber bitte keine mehr um die dateigröße, denn das hat sich schon geklärt!

gruss zor

[Nirvana]

gedacht ist das so, dass die satelliten mit den transpondern im root liegen und beim ersten scan die benötigten rausgepickt werden

Ich will keinen Scan. Ich will die Services, wie usul schon richtig erkannt hat, einfach aus dem Internet laden. Eine explizite Sendersuche ist doch nun echt von vorvorgestern.

[herbyhide]

also ich muss auf 28,2 immer noch einzeln abscannen da dort der ssd.scan gesprengt wird!!

[dietmarw]

Ich will keinen Scan. Ich will die Services, wie usul schon richtig erkannt hat, einfach aus dem Internet laden

ihr werdet lachen, es soll doch wirklich boxen geben die keinen netzzugang haben

[usul1]

ihr werdet lachen, es soll doch wirklich boxen geben die keinen netzzugang haben

Ach, erzähl doch nicht solche Märchen. Wir haben 2006 da brauchen die Haushaltsgeräte doch ihren Internetzugang ;-)

Wobei diese ganze Sache natürlich auch funktionieren sollte wenn die Box nicht am Internet hängt. Und das tut es ja auch.
Nur weil es möglich ist (wäre, wenn das neue Format einwenig clever ist) eine Kanalliste zu nutzen die im Netz liegt bedeutet das ja nicht das man es muß.

ich hätte noch gerne ein paar meinungen zum format - aber bitte keine mehr um die dateigröße, denn das hat sich schon geklärt!

Ich weiß nicht ob der Vorschlag einfach nur Untergegangen ist oder höflich ignoriert wurde weil er zu blöd war. Aber was ist mit dem speichern des Datums an dem ein Sender in die Liste eingetragen wurde?
Dann könnte man sich alle neuen (seit einer Woche, zwei Wochen usw.) anzeigen lassen und entscheiden ob man sie gerne in den Favoriten hätte.

Alternativ könnte man auch nur einfach ein "neu" Flag nehmen welches man manuell löschen kann. D.h. irgendwo in der GUI ist ein Menüpunkt "alle "neu" Makierungen zurücksetzen".

Ansonsten ist es ja OK. Eine Liste wo alle Services mit allen verfügbaren Informationen reinkommen. Und dann noch mit der Möglichkeit einige dieser Informationen zu überschreiben wenn die Sender Blödsinn senden.
Das klingt doch gut.

Was mir hier allerding zu kurz kommt ist die Frage wie denn jetzt die eigenen Favoritenlisten verwaltet/gespeichert werden.


BTW: Die Idee jedem Sat seine eigene settigsdatei zu spendieren gefällt mit immer besser. Wenn dann die persönlichen Daten (Favoriten) aus der Senderliste verschwunden sind könnte man z.B. fertige service Listen zum Download anbieten. Und wie schon gesagt man könnte die service Listen Dateien auf meheren Boxen gemeinsam nutzen.

BTW2: Evtl. könnte man dann auch mal endlich ne service Liste für Astra und Hotbird zusamen mit einer vorsortierten Favoritenliste (Deutsches Free TV) ins Baseimage legen.
Schließlich ist eine schon vorhandene Kanalliste mittlerweile Stnadrt bei neuen Receivern. Und das ist zum Anfangen auch garnicht verkehrt.

cu
usul