Kleiner Bouquet Bug

Moin,
also, ich habe z.B. ein Bouquet PREMIERE und ein Bouquet SPORT. in beiden Bouquets sind die Sender SPORT1 und SPORT2 drin. Das Bouquet SPORT liegt hinter dem Bouquet PREMIERE.

Bin ich nun im Bouquet SPORT, und zappe mit den Pfeiltasten zwischen SPORT1/2 hin/her, und drücke dann OK um das Bouquet aufzurufen, befinde ich mich aber im Bouqet PREMIERE

Es wird, sofern Sender doppelt eingetragen sind, immer zum ersten Bouquet gesprungen, habe ich den Eindruck. Ist mir vor ein paar Tagen erst aufgefallen, ob das schon immer so war kann ich nicht beurteilen. Zumindest mit dem aktuellen CDK ist es der Fall.

Dieses Verhalten kannst du auch an anderen Stellen beobachten (z.B. Standby).
Der Grund ist relativ einfach:
Intern wird alles nach einer channel_id verwaltet, die (zumindest auf Astra) einen Sender (Service) eindeutig identifiziert. Es wurde nun alles so designed, dass per channel_id gezappt wird.
Das Problem ist, dass man von der channel_id nicht mehr auf die Kanalnummer zurueckschliessen kann, sofern sich ein Sender (Service) in mehreren Bouquets befindet.
Mit der libzapitclient kann man problemlos ohne Kanalnummer und nur mit channel_id zappen (dies wird auch intern meist so gemacht). Neutrino bekommt das mitgeteilt, aber weiss natuerlich nicht, welche Kanalnummer gemeint ist (beachte: nicht nur neutrino . Folglich speichert Neutrino auch die Kanalnummer nicht (vgl.

Code: Alles auswählen

apps/tuxbox/neutrino/src/gui/channellist.cpp

).
Die Identifikation via Kanalnummer hat auch ihre Tuecken: Wie soll z.B. eine Zuordnung stattfinden nach einer Kanalsuche mit Aenderung der Bouquets? Was passiert mit Timerevents, wenn mit einem externen Bouqueteditor die Kanalnummern geaendert werden, usw.
Somit ist ein echter Fix schwierig und hoechstens workarounds moeglich.

Hi,
OK - ich spare mir jetzt das zitieren (war sehr ausführlich erklärt, danke!).
Habe auch eh selten Sender doppelt in den Bouquets, kann man also gut mit leben, wenn man es weis.

Abhilfe würde vielleicht bringen, wenn die Daten tatsächlich aus den Bouqets gelesen werden würden. Damit wäre auch der Wunsch vieler befriedigt, das tatsächlich der Channelname aus den Bouquets genutzt wird - und nicht der aus den Services. Aber zu große Priorität würde ich dem auch nicht geben.

Beitrag von **essu** » Donnerstag 12. Februar 2004, 12:43

thegoodguy hat geschrieben:[...]Somit ist ein echter Fix schwierig und hoechstens workarounds moeglich.

Naja, aber neben einer channel_id auch noch eine bouquet_id zu speichern, kann so schwierig doch nicht sein und

Code: Alles auswählen

coding = coding.workaround

BTW: In der Timerliste müssten halt die (meist) eindeutigen Identifikatoren für einen Kanal gespeichert werden und die channel_id erst beim Abarbeiten des Timers aus der services.xml eingelesen werde. Klar kann mann nicht verhindern, dass zur Aufnahmezeit ev. der Kanal nicht verfügbar ist. Aber solche Strukturprobleme kann man IMHO schon umgehen.

@essu: Es steht dir jederzeit frei es zu fixen, aber bedenke, dass z.B. der nhttpd einfach zapit eine channel_id mitteilt, der dann zapt und neutrino das Resultat von zapit erfaehrt und einfach sich zu der channed_id den erstbesten kanal schnappt.
Folglich muesstest du die zapit -> neutrino kommunikation aufbohren, i.e. insbesondere auch die interne kommunikation in neutrino, d.h. statt 32bit channel_id musst du stets speicher allokieren und die datenstruktur durchschleifen (dies wird fuer andere datenstrukturen bereits gemacht) und dann an der richtigen Stelle den Speicher wieder freigeben.
Aber voellig trivial ist das nicht.
Auch impliziert die Aenderung, dass evtl. alle grab-Programme angepasst werden muessen und nicht mehr per channel_id zappen koennen ...
Ich bin dir auf keinen Fall boese, wenn du es schnell hinbekommst.

Also die Channel_ID wird, wenn ich das richtig verstanden habe, in den Daten des Service vom Satelliten mitgesendet?!?
Ist das dann auch der Grund warum Neutrino dann in megalangen Senderlisten (mehrere Satelliten) teilweise falsche Services identifiziert weil ggf. die Channel_IDs übereinstimmen?

Dann wäre es ja wahrscheinlich am sinnvollsten neben der Channel_ID auch noch die Satelliten-Position und ggf. Bouqet_ID zu verwenden um einen Service eindeutig zu identifizieren, oder?

Das Problem ist dann "nur" das halt die Umsetzung scheinbar ziemlich schwierig ist...

Ist das dann auch der Grund warum Neutrino dann in megalangen Senderlisten (mehrere Satelliten) teilweise falsche Services identifiziert weil ggf. die Channel_IDs übereinstimmen?

Ja, aber im Prinzip waeren 32 bit doch genug fuer alle, bloss wer erklaert das den Satellitenbetreibern?
Also muesste eine sat_id und evtl. z.B. die transponder_id noch mit codiert werden (=> 64 bit), aber das wirft einige Probleme im sectionsd auf, da der z.B. einen Satellitenwechsel gar nicht mitbekommt und dies aus den empfangenen sections imho nicht ermitteln kann. Die bisherige epg_id mit 64 bit klappt dann natuerlich auch nicht mehr, da davon 32 bit channel_id sind, usw.
Fazit: Die Aenderung braeuchte genau Kenntnisse der Neutrino Internas und viel Zeit zum aendern und testen. Auch sollte man mehr als nur Astra haben.
=> Das Problem ist genauso wie bei den ganzen privaten Kabelbetreibern: Die wenigen, die was exotisches haben, scheinen das Problem nicht loesen zu wollen und/oder koennen und die anderen haben es gar nicht.

Stimmt, 32-Bit sollten wirklich genug sein...

Das Problem ist wahrscheinlich nur, das jeder Satelliten-Provider seine IDs selber vergibt/vergeben kann und es keine zentrale Stelle gibt, die diese IDs vergibt.

Kann man denn nicht die Orig. ID austauschen und eine eigene erstellen (berechnen) die dann eine Überschneidung vermeidet? Dann bräuchte man auch nicht die "32Bit-Grenze" zu überschreiten.
Vermutlich müsste diese Umrechnung ja nur einmal stattfinden beim Sendersuchlauf, oder liege ich da falsch?!?

DarkSoul hat geschrieben: Kann man denn nicht die Orig. ID austauschen und eine eigene erstellen (berechnen) d

So mache ich das bisher (manuell), da speziell 0001 öfters vorkommt. Dummerweise kann man auch nicht irgendwie eintragen was man möchte. Also z.B. geht anstelle von 0001 die 1111, aber warum und wieso - frag mich nicht

Findest Du denn da ein System was funktioniert und was nicht? Bei ein paar Tausend Services die ich von 42Â°E bis 45Â°W empfange wird es schwierig das alles von Hand zu fummeln...

Hat die Channel_ID denn noch irgendeine Funktion (ähnlich den PIDs) oder ist das einfach nur eine ID die zur Info/Erkennung mitgesendet wird?

EDIT:
Schaue mir gerade nochmal die XML-Listen an. Wahrscheinlich wird die Channel_ID auch zu Identifizierung des Service auf dem Transponder verwandt, da in der Services.xml ja keine PIDs gespeichert werden.Die werden dann wahrscheinlich nach dem Zappen vom Transponder ermittelt um bei evtl. PID-wechseln einen erneuten Sendersuchlauf überflüssig zu machen. Oder vermute ich da falsch?

DarkSoul hat geschrieben:Findest Du denn da ein System was funktioniert und was nicht?

Nö, und auch im Forum hier (gibt es etliche Threads zu) keine Antwort gefunden - darum habe ich es aufgegeben. Ich erstelle meine Liste von Hand, filtere die doppelten raus (meistens hat man Glück, und kann codierte löschen, welche man eh nicht sehen kann). Dann habe ich eine saubere Liste.
Dann habe ich den Newsletter von Lyngsat abonniert, und bei wichtigen Änderungen mache ich die 1-2mal pro Woche von Hand. Der Aufwand hält sich in Grenzen, auch wenn man mehrere Sats empfängt (OK, ich habe nur 3). Alles andere führt zu nichts, da ja die Kanalsuche auch viele Sender nicht findet (Dieses Problem liegt aber wieder woanders).

Hat aber den Vorteil, eine aufgeräumte Liste zu haben, ohne Sonderzeichen etc.. Astra/Hotbird/Sirius stelle ich regelmäßig zum Download bereit. Falls Interesse, PM me.

Nachtrag: Ja, APID/VPID nimmt er die, welche er gesendet bekommt. Wird kjeine gesendet, hast Du Pech - auch wenn sie Dir bekannt ist. Zum Beispiel bei dem rumänischen TV Sport auf Sirius.

Danke für das Angebot, aber Astra und HB funzen ja eh schon so (fast) Problemlos. Interessant wäre das nur wenn es für alle Satelliten irgendwie klappen würde bzw. wenn es ein System gäbe...

Wäre es denn nicht möglich eine zusätzliche ID einzufügen die dann service_ID heißt (und die gleiche Funktion wie die Channel_ID hat) und die jetzige Service_ID als zb. SID abzulegen? Wieviel Aufwand wäre das denn sowas (als Option?) in ZapIt hinzuzufügen? Wenn ich das richitg verstehe müssten dann z.B. der nhttpd oder der Timer o.Ä. nicht umprogrammiert werden.
Natürlich hätte man dann das Problem das nach einem erneuten Sendersuchlauf einiges nicht mehr passt und man ggf. die eigenen Bouquets und Timer anpassen müsste.
Damit könnte ich natürlich sehr gut leben - andere jedoch wahrscheinlich nicht... *seufz*

Beitrag von **essu** » Donnerstag 12. Februar 2004, 15:39

thegoodguy hat geschrieben:[...] aber bedenke, dass z.B. der nhttpd einfach zapit eine channel_id mitteilt, der dann zapt und neutrino das Resultat von zapit erfaehrt und einfach sich zu der channed_id den erstbesten kanal schnappt.
Folglich muesstest du die zapit -> neutrino kommunikation aufbohren, i.e. insbesondere auch die interne kommunikation in neutrino[...]
Ich bin dir auf keinen Fall boese, wenn du es schnell hinbekommst.

Zumindest das eingangs geschilderte Problem liesse sich mit einem Eintrag in der zapit.conf: CURRENTBOUQUET=x lösen.

Sag ich mal so in meinem jugendlichen Leichtsinn.

Und auch das Timerproblem liesse sich lösen, wenn zunächst auf eindeutige Satelliten-Daten Bezug genommen würde.

Momentan bin ich mit meiner Services und Bouquets aus dem Internet laden ausgelastet (BTW.: Demnächst lässt sich der Download auch über Neutrino-Bouquets konfigurieren), aber wenn das mal läuft zieh ich mir C rein

und machs, ich will mch ja nicht drücken, aber alles zugleich geht nicht...

essu hat geschrieben:Und auch das Timerproblem liesse sich lösen, wenn zunächst auf eindeutige Satelliten-Daten Bezug genommen würde.

Mal so am Rande: Sind denn die Channel_IDs wenigstens auf ein und demselben Satelliten immer eindeutig, oder gibt es auch Sat-Provider die z.B. alle Sender 0001 nennen?

channel_id ist ein kuenstliches Konstrukt, vgl. http://cvs.tuxbox.org/cgi-bin/viewcvs.c ... cvs-markup: Aktuell ist

Code: Alles auswählen

typedef uint32_t t_channel_id;
#define CREATE_CHANNEL_ID ((original_network_id << 16) | service_id)

, besser waere

Code: Alles auswählen

typedef uint64_t t_channel_id64;
#define CREATE_CHANNEL_ID64 (((uint64_t)satellitePosition << 48) | ((uint64_t) transport_stream_id << 32) | ((uint64_t)original_network_id << 16) | (uint64_t)service_id)

.

DarkSoul:

Das Problem ist eigentlich die onid uns serviceid. Hier einige Problemfälle auf Hotbird 13E:









Sollte als Beispiel genügen, da sind noch mehrere mit onid="0001"

Resultat: Alle, welche onid=0001 und eine gleiche sid haben (z.B. auch 0001) gehen nicht, bzw. es geht nur der erste Eintrag, welcher in der services.xml gefunden wird. Und obiges ist jetzt ausschließlich Hotbird - und leider alles FTA Sender. Je mehr Satelliten Du hast, desto größer wird Dein (meins auch) Problem

Beitrag von **HEAD** » Donnerstag 12. Februar 2004, 19:03

???
>>#define CREATE_CHANNEL_ID ((original_network_id << 16) | service_id)
also hier ist doch service_id="0064" und der sender geht bei mit.
transponder id ist 012c aber mit 0001 geht auch.

HEAD,
ja, ich hatte oben bei mir angefangen und der Reihe nach ein paar Beispiele genannt. Entschuldige!

Problematisch sind die Sender, welche eine onid von 0001 sowie eine service_id von 0001 haben, usw. Von denen geht jeweils nur der erste in der services.xml, und davon gibt es leider mehrere auf dem gleichen Sat (13E).
Ferner auch noch auf 5E.

PS: Wie kommst Du darauf der Transponder wäre 012c?

Beitrag von **HEAD** » Donnerstag 12. Februar 2004, 21:46

>>PS: Wie kommst Du darauf der Transponder wäre 012c?

PID: 17 (0x0011)
SDT-decoding....
Table_ID: 66 (0x42) [= service_description_section - actual transport stream]
section_syntax_indicator: 1 (0x01)
reserved_1: 1 (0x01)
reserved_2: 3 (0x03)
Section_length: 84 (0x0054)
Transport_Stream_ID: 300 (0x012c) <<<<<<< HIER
reserved_3: 3 (0x03)
Version_number: 0 (0x00)
current_next_indicator: 1 (0x01) [= valid now]
Section_number: 0 (0x00)
Last_Section_number: 0 (0x00)
Original_network_ID: 1 (0x0001) [= Astra Satellite Network 19,2Â°E | SociÃ©tÃ© EuropÃ©enne des Satellites]
reserved_4: 255 (0xff)

Service_id: 100 (0x0064) [= --> refers to PMS program_number]
reserved_1: 63 (0x3f)
EIT_schedule_flag: 1 (0x01)
EIT_present_following_flag: 1 (0x01)
Running_status: 4 (0x04) [= running]
Free_CA_mode: 0 (0x00) [= unscrambled]
Descriptors_loop_length: 27 (0x001b)

DVB-DescriptorTag: 72 (0x48) [= service_descriptor]
Descriptor_length: 25 (0x19)
Service_type: 1 (0x01) [= digital television service]
Service_provider_name_length: 13 (0x0d)
Service_provider_name: "T-Systems/MTI" -- Charset: Latin alphabet
Service_name_length: 9 (0x0009)
Service_name: "Punto Sat" -- Charset: Latin alphabet

Service_id: 101 (0x0065) [= --> refers to PMS program_number]
reserved_1: 63 (0x3f)
EIT_schedule_flag: 1 (0x01)
EIT_present_following_flag: 1 (0x01)
Running_status: 4 (0x04) [= running]
Free_CA_mode: 0 (0x00) [= unscrambled]
Descriptors_loop_length: 35 (0x0023)

DVB-DescriptorTag: 72 (0x48) [= service_descriptor]
Descriptor_length: 33 (0x21)
Service_type: 1 (0x01) [= digital television service]
Service_provider_name_length: 13 (0x0d)
Service_provider_name: "T-Systems/MTI" -- Charset: Latin alphabet
Service_name_length: 17 (0x0011)
Service_name: "Test for Puntosat" -- Charset: Latin alphabet
CRC: 2156791270 (0x808e05e6)

HEAD hat geschrieben: Original_network_ID: 1 (0x0001) [= Astra Satellite Network 19,2Â°E |

Da kann ja wohl was nicht stimmen - oder? Wir reden doch noch von Hotbird 13E?? Und die TRANSPORT_Stream_ID ist sicher nicht das gleiche wie die TRANSPONDER-ID - oder? Hmm.. oder doch?

PS: hast Du das mit DvbSnoop gemacht? Wenn das mit einer aktuellen Version war, ist das ein Bug - DvbSnoop geht offensichtlich fälschlicherweise davon aus, bei einer onid von 1 würde es sich um Astra 19.2E handeln? Hmm.. keine Ahnung. Blicke durch DvbSnoop auch nicht so ganz durch. Entweder Bug oder user fatal error

Beitrag von **HEAD** » Donnerstag 12. Februar 2004, 22:17

Das stimmt schon , so etwas kommt öfter auf HB13Â° vor.

HEAD hat geschrieben:Das stimmt schon , so etwas kommt öfter auf HB13Â° vor.

Dann ist das aber doch ein Bug in den Drivern (wegen doppelter ONIDs, etc..) oder ein Bug in DVBSNOOP.
Es kommt sicherlich überhaupt nicht vor, das sich die Firma Eutelsat mit SES Astra meldet - das bezweifle ich doch mit meinem gesunden Menschenverstand recht stark!

Ferner ist auch (jetzt mal ganz unabhängig davon) die TID sicherlich ganz was anderes als die ID des Transport Streams.

Beitrag von **DarkSoul** » Freitag 13. Februar 2004, 09:32

thegoodguy hat geschrieben:besser waere

Code: Alles auswählen

typedef uint64_t t_channel_id64;
#define CREATE_CHANNEL_ID64 (((uint64_t)satellitePosition << 48) | ((uint64_t) transport_stream_id << 32) | ((uint64_t)original_network_id << 16) | (uint64_t)service_id)

.

Verstehe ich das falsch, oder heißt das dann das schon entsprechende neue Routinen drin sind, aber aus div. Gründen noch nicht verwandt werden (können)?

thegoodguy hat geschrieben:
Code: Alles auswählen
#define CREATE_CHANNEL_ID ((original_network_id << 16) | service_id)

Was ich jetzt an der alten wie auch an der alternativen Variante nur nicht ganz verstehe ist das "<< xx" Habe gerade mal inner C-Referenz geblättert und wenn da wirklich Bits verschoben werden verstehe ich jetzt nicht ganz warum!?

Und warum die ODER-Verknüfpung zwischen ONID und SID?

Sorry, das ich jetzt so Kleinigkeiten nachfrage (büdde büdde nich hau en

), aber ich versuche mich gerade da reinzudenken und die Problematik zu verstehen - leider habe ich nur null Plan von C!

@DarkSoul: Neutrino besteht aus mehreren Komponenten:
zapit, sectionsd, timerd, nhttpd und die eigentliche neutrino gui.
Seit 1-2 Jahren, kann zapit prinzipiell mit 64 bit channel_id's umgehen (es fehlen da nur sehr geringfuegige Modifikationen, evtl. ist es im Laufe der Zeit ein wenig mehr geworden). Leider kann man dies von den anderen Komponenten nicht behaupten. Da muesste Zeit investiert werden und auch die meisten Zusatzprogramme (z.B. Grabprogramme, evtl. Bouqueteditoren) angepasst werden.
original_network_id ist 16 bit, service_id auch. ((original_network_id << 16) | service_id) ergibt eine 32 bit zahl, die hoeheren 16 bit sind die original_network_id. | ist ein binaeres oder und hat in diesem fall die bedeutung von +. Also sind zwei channel_id's gleich genau dann wenn sowohl die original_network_id als auch die service_id gleich sind.

@en-total: die doppelte original_network_id + service_id ist kein Treiberbug, sondern ein Hotbirdbug, die halten sich nicht an den DVB-Standard.

Beitrag von **Janus** » Freitag 13. Februar 2004, 10:53

Schön, daß nach so langer Zeit der 'kleine Bug' wieder angesprochen wird.

Standard hin, Standard her -
die Komination ONID:TSID:SID ist für eine Sat-Position eindeutig! Mit einer Broadcaster-ID (SatPos) wäre sie zweckgemäß vollständig.
Die Gefahr ist ja auch erkannt (t_channel_id64

)

Viele andere Receiver-Hersteller haben den Weg über ONID:SID beschritten (der ja auch Vorteile z.B. für 'AutoUpdates', NVOD-Subfeeds bietet) und sind nur mit selbstgewählten 'Fake'-ONIDs etwas weitergekommen (Humax FTV5600 u.A.), um diese Problematik in den Griff zu bekommen. Postings zu diesem Thema (und den deshalb nicht zu tunenden Services) waren vor Jahren Legion.

Aber wie schon angedeutet: Immer waren es die Prioritäten oder die fehlende 'Deckung' von Equipment und Skill, die eine durchgehende Anpassung an die korrekte Relation verhinderte.

Aber vielleicht wird es ja jetzt was, evtl. im Zusammenhang mit den 'kleinen' Symbolraten...

Janus