Neutrino: Sendernamen aus bouquets.xml auf OSD/Display

Hallo,

ich wüßte gerne warum in der bouquets.xml der Sendername nochmal abgespeichert wird, wo er doch in der services.xml bereits enthalten ist.

Ich dachte man könnte diesen Namen in der bouquets.xml editieren, wenn man z.B. wie ich keine reine Großschreibung möchte (sieht einfach nicht aus). Das wäre in meinen Augen der einzige sinnvolle Grund, warum der Sendername in der bouquets.xml nochmal gespeichert wird.

Allerdings verwendet Neutrino bei der Darstellung im OSD und Display stur die Schreibweise aus der services.xml.

Naja, wenn man die Bouquets mit 'nem Texteditor editiert sind die Sendernamen in der Bouquets.xml doch recht hilfreich.
Du kannst sie ja rausloeschen um die Bootzeit von Neutrino marginal zu verkuerzen

.

Beitrag von **Sepp776** » Mittwoch 3. Dezember 2003, 23:14

Moin Moin!

Spricht denn was dagegen die Namen aus der bouquets.xml zu nehmen? Teilweise kann man schon die Übersicht verbessern, wenn man eigene Namen vergibt, finde ich...

Ciao,
Sepp.

Ja, die aktuelle Datenstruktur von zapit.
Die Informationen zu den einzelnen Kanaelen in der bouquets.xml dienen ausschliesslich dazu den entsprechenden Kanal in der services.xml zu finden.
Intern wird folglich ein Bouquet als eine Liste von Zeigern auf die einzelnen Kanaele representiert. Die aktuelle Representation ist folglich auch recht effizient.
Du kommst deshalb nicht herum den Kanal in den services.xml anders zu benennen.

Beitrag von **Sepp776** » Mittwoch 3. Dezember 2003, 23:48

ah, verstehe. Ich dachte die Zuordnung ginge mit serviceID, tsid und onid. Reicht das denn nicht für eindeutige Zuordnung?

Sie laeuft derzeit sogar nur mit serviceID und onID, wobei zapit sehr einfach auf satellitID+serviceID+tsid+onid umgestellt werden koennte.
Leider kann der sectionsd und neutrino damit nicht umgehen, da dies im urspruenglichen Design nie vorgesehen war (bei zapit war es urspruenglich auch nicht).
Sectionsd waere eine groessere Aktion und bei Neutrino klemmts vor allem im Eventhandling, das 32-bittig ist und fuer ne eindeutigere ID braeuchte es mindestens 64 bit.
Deshalb der aktuelle Zustand.

Danke für die Erklärungen.