Jump to content

API: Neue Channel-IDs in der Timerliste?


Recommended Posts

Wenn ich die Timerliste in der neue 1.7.x über die API abrufe, passen die Ids nicht mehr. Im Changelog stand irgendwas von Umstellung auf 64Bit-Ids.

Was genau hat sich da geändert?

 

Nochmal mein Stand zu dem ID-Chaos am Beispiel "ZDF_neo":

 

Bis zur 1.6.9 bekam ich in der Timerliste diese ID: 1117678958

Die hat aber natürlich nix mit der Id zu tun, die ich beim Abruf des EPG angeben muss: 562954319129968

Das wäre ja zu einfach.

Und jetzt seit der 1.7.x bekomme ich in der Timerliste diese ID: 2359890840129531246

 

Ich weiss nicht, ob diese vielen unterschiedlichen IDs nur dazu dient, die API-Programmierer zu verwirren, oder ob da ein höherer Sinn dahinter steckt.

 

Und dann natürlich alles 64-Bit-Arithmetik in Dezimaldarstellung (grusel!) Das macht unheimlich Spass, wenn man keinen Unsigned Double Long Integer hat. In Hex könnte man sich das in jeder Sprache einfach zusammenbauen. Aber auch das wäre ja viel zu einfach.

Edited by dgdg
Link to comment

Die Bedeutung der niederwertigen Bits 0..31 ist unverändert. Hinzugekommen sind

 

Bit 32..47 Transportstream ID (16 Bit)

Bit 48..60 Orbitalposition in Grad mal 10 (13 Bit, bei DVB-T/C-Pseudo-Gradzahlen 500/400).

Bit 61..62 TV/Radio-Flag (2 Bit, 0 = undefiniert, 1 = TV, 2 = Radio)

Bit 63 reserviert.

Link to comment

Ich hatte die alten IDs nicht berechnet, sondern hatte sie mir einfach aus der Konfigurationsdatei vom TVinfo-Importtool geklaut. ;-)

Die Berechnung habe ich nicht hinbekommen. Meine Ergebnisse stimmten nie überein.

 

Kannst du mir bitte auch nochmal die Bedeutung der Bits 0..31 posten? Dann versuche ich es nochmal mit berechnen.

Link to comment

..es gibt grundsätzlich noch ein ziemliches durcheinander, da z.b. auch die favoriten nicht automatisch upgedatet werden. Dort findet man noch die kuze form, wenn man nichts geändert hat. Fiel mir gerade auf, als ich einen sender einstellen wollte, der nicht mehr in meiner liste war (root von dem satelliten hatte ich gelöscht). Der DVBViewer sprang fröhlich auf einen astra-radiosender, obwohl ich einen HD-sender von einer anderen position angefordert hatte (w00t)

Link to comment
Die Berechnung habe ich nicht hinbekommen.

Muss man ja auch nicht. DVBViewer Pro Senderlisten Editor -> Rechtsklick auf Sender -> ID in Zwischenablage.

Link to comment

Muss man ja auch nicht. DVBViewer Pro Senderlisten Editor -> Rechtsklick auf Sender -> ID in Zwischenablage.

 

Super, für die alte Id klappt das. Und wo kann ich die neue 64bit-Id rauskopieren?

 

Das Berechnen habe ich inzwischen aufgegeben. Ist mit 32Bit-Arithmetik definitiv nicht hinzubekommen. Es scheitert an der Umwandlung in den Dezimalwert. Hex wäre wie gesagt überhaupt kein Problem. Und mit Real-Typen klappt es auch nicht, weil auch da die Genauigkeit der Mantisse nicht ausreicht. Die hat nur 57Bit bei 64it-Real-Zahlen.

 

Vielen Dank. Damit kann ich mein Programm dann in die Tonne tun, weil der Aufwand wird jetzt gerade unverhältnismäßig.

Edited by dgdg
Link to comment
Super, für die alte Id klappt das. Und wo kann ich die neue 64bit-Id rauskopieren?

Eine interne Testversion liefert mir die 64-Bit-ID, z.B.

 

2359890934581587402|Das Erste (deu)

 

aber ich habe keine 4.6.0.1 zur Hand, mit der ich überprüfen kann, was sie ausgibt.

 

32 Bit IDs funktionieren nach wie vor, da der DVBViewer die hinzugekommenen Werte als undefiniert ansieht, wenn sie = 0 sind, und quasi als "Joker" verwendet, die zu allem passen. Nur die Trennschärfe ist dabei verringert bzw. nicht besser, als sie vorher war. Auf Kompatibilität wurde bei der Umstellung geachtet.

 

Mit dem Windows-Taschenrechner kann man die 64-Bit-ID so berechnen:

 

Service ID + AudioPID x 216 + (Tunertyp+1) x 229 + TransportstreamID x 232 + (OrbitalPosition x 10) x 248 + TVRadioValue x 261

 

Hex wäre wie gesagt überhaupt kein Problem.

Dann baue die ID als Hex zusammen und setze ein $ davor, z.B.

 

$20C0044D40666DCA|Das Erste (deu)

 

Soweit ich feststellen kann, liest der DVBViewer Pro das ein... wenn Lars die Routinen aus der GE übernommen hat, in der es die 64 Bit-ID schon länger gibt, muss es funktionieren.

 

Vielen Dank. Damit kann ich mein Programm dann in die Tonne tun, weil der Aufwand wird jetzt gerade unverhältnismäßig.

Mensch, sei doch nicht gleich so negativ.

Link to comment

Vielleicht solltest du auch überlegen irgendeine Sprache zu nutzen, die einen 64Bit Dezimaldatentyp hat...? Immerhin ist das bei den meisten Sprachen schon mit der Umstellung der Rechnerarchitekturen von 16Bit auf 32Bit passiert... seit dem liefert z.B. bei C/C++ der long integer eine 64Bit Zahl. So richtig nachvollziehen, was da jetzt bei dir kein 64Bit Dezimal kann, kann ich ehrlich gesagt nicht.

 

Was mich bei der Problematik aber mal interessieren würde ist, wo die ID, die der Service beim EPG-Abruf verwendet, in dem System einzuordnen ist... Bleiben diese extra IDs? Oder wird hier in (naher?) Zukunft auf die 64Bit IDs umgestellt? Das ist schon irgendwie ärgerlich, dass da mit ganz anderen IDs gearbeitet wird (auch wenn die Audio ID für den EPG Datenstrom keinen Sinn macht, oder?)...

Edited by Moses
Link to comment
Bleiben diese extra IDs? Oder wird hier in (naher?) Zukunft auf die 64Bit IDs umgestellt?

Das sind bereits 64-Bit-Werte, und nein, die werden nicht umgestellt :) Für den EPG müssen Sender über Angaben zugeordnet werden, die in der EIT stehen:

 

Bit 0..15: Service ID

Bit 16..31: Transportstream ID

Bit 32..47: Original Network ID

Bit 48..50: Tunertyp + 1

Bit 51..63: Reserviert (= 0)

 

Wenn du mal einen Blick in den TransEdit Analyzer wirfst... den Tunertyp nimmt der DVBViewer noch hinzu, denn wenn er eine EIT empfängt, weiß er natürlich auch, mit welchem Tuner.

 

auch wenn die Audio ID für den EPG Datenstrom keinen Sinn macht,

So ist es. Die Sender-ID für Favoriten / Timer / Kommandoparameter usw. muss verschiedene Audiospuren unterscheiden, was beim EPG sinnlos wäre.

 

Im Grunde handelt es sich bei den IDs jedoch nur um eine Schikane, die wir uns ausgedacht haben, um dgdg zu ärgern. Und Derrick, den kann man damit auch so schön auf die Palme bringen :devil:

Link to comment
×
×
  • Create New...