[384.1] vor Providername nach Suchlauf

Antworten
Benutzeravatar
Nanobot
Beiträge: 134
Registriert: Do 21. Feb 2019, 20:26
Box: Zgemma H7C, Coolstream Zee

[384.1] vor Providername nach Suchlauf

Beitrag von Nanobot »

Hi Leute,

für langjährige Benutzer des NI Images möglicherweise eine dumme Frage, aber ich habe erst vor einigen Tagen zum Ansehen mal das NI Image in meine Reservebox, eine Zee1, geflasht. Davor habe ich das letzte BP 2.5 Beta verwendet.

Nun die Frage: Kann man irgendwo abschalten, daß nach einen Suchlauf vor dem Namen der Anbieterbouquets diese Pseudo-Positionsangabe steht ? Der Name soll also zum Beispiel nicht "[384.1] ARD" sondern wie früher nur "ARD" lauten. Wenn man nur Kabel hat, diese Positionsangabe ja sinnlos, denn man hat ja nicht im gleichen Hause Kabel von zwei verschiedenen Anbietern.

C.U. Nanobot
Zgemma H7C NI 4.00.95, NI 4.10.105.119, BPanther 19746, BPanther 19860
Benutzeravatar
annie
NI - Team
Beiträge: 1010
Registriert: Di 5. Apr 2016, 18:46
Wohnort: zuhause
Box: 1x E4HD, 4x HD51,1x VuUno4K

Re: [384.1] vor Providername nach Suchlauf

Beitrag von annie »

Wird in Abhängigkeit zur /var/tuxbox/config/cables.xml erstellt.

Erstell dir eine eigene Transponderliste (cables.xml), die kannst du dann benennen wie du willst.

Settings löschen und dann neuen Suchlauf...

Übrigens so eine cables.xml habe ich bisher noch nirgends aktuell gefunden.
Benutzeravatar
Miky
NI - Team
Beiträge: 1213
Registriert: Di 5. Apr 2016, 17:17
Box: Tank,Trinity,Neo 1,Neo2,Neo²,HD51
Been thanked: 1 time

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Miky »

Denke für z.B. vodafone bekommt man hier was ziemlich Aktuelles: https://helpdesk.vodafonekabelforum.de/ ... egung.html

Nachdem man Bundesland, Stadt etc ausgewählt hat, kann man am Ende der Providerliste sich das Ganze für Neutrino exportieren.
Boxen: Neo 1, Neo2 , Neo², Trinity, Tank, HD 51 alle SAT
Kein PN Support!
Benutzeravatar
vanhofen
Administrator
Beiträge: 2924
Registriert: Di 5. Apr 2016, 00:05
Has thanked: 2 times
Been thanked: 10 times

Re: [384.1] vor Providername nach Suchlauf

Beitrag von vanhofen »

Nanobot redet von den Bouquet-Namen, die aus cables/satellites.xml resultieren, nicht von den XMLs selbst.
Dass die Bouquets mit [POS] geprefixt werden, ist sicherlich einstellbar zu machen. Sicher bin ich mir da aber gerade nicht. Ich schreibe es mir mal mit auf.
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Janus »

Ich habe in meinen Sourcen die providermap.xml um eine Broadcaster-ID erweitert. Die ermöglicht es, gezielt anhand dieser ID (pos=dddd) die (anwenderfreundlichen) Providernamen zuzuweisen.

E 13.0 Sky it
E 19.2 Sky de
E 28.2 Sky en
C F01 Sky um
T E11 ARD

Beispiel (ex) UnityMedia:

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>
<zapit api="4">
  <BC bcID="3841">
    <TS name="ARD" newname="ARD um"/>
    <TS name="ARD WDR" newname="ARD um Radio"/>
    <TS name="ARD BR" newname="ARD um Radio"/>
    <TS name="ARD HR" newname="ARD um Radio"/>
    <TS name="ARD SR" newname="ARD um Radio"/>
    <TS name="ARD MDR" newname="ARD um Radio"/>
    <TS name="ARD NDR" newname="ARD um Radio"/>
    <TS name="ARD RB" newname="ARD um Radio"/>
    <TS name="ARD rbb" newname="ARD um Radio"/>
    <TS name="ARD SWR" newname="ARD um Radio"/>
    <TS name="BetaDigital" newname="BetaDigital"/>
    <TS name="BetaResearch" newname="BetaDigital"/>
    <TS name="betaresearch" newname="BetaDigital"/>
    <TS name="HMS GmbH" newname="HMS GmbH"/>
    <TS name="Sky" newname="Sky um"/>
    <TS name="SKY" newname="Sky um"/>
    <TS name="ZDFvision" newname="ZDF um"/>
    <TS name="UMKBW" newname="UnityMedia"/>
    <TS name="Unitymedia" newname="UnityMedia"/>
    <TS name="Unitymedia - STINGRAY MUSIC" newname="StingrayMusic"/>
  </BC>
</zapit>

Darüberhinaus habe ich in meinem Source die Prefixe für Kabel und Terrestrik auf Hex mit entsprechender Delivery-Kennung (C oder T) umgestellt, sodass sich bei MultiSat-/Multituner-Installationen ein gleichmäßiges Bild bei der Bouquet-Liste ergibt.
Bei solchen Systemen macht es natürlich keinen Sinn, diese Prefixe wegzulassen.
Dateianhänge
0005-mine-change-bouquetprefix-C-and-T-to-hex.patch
(1.46 KiB) 83-mal heruntergeladen
0001-mine-add-element-bcID-to-providermaps-xml-structure.patch
(7.1 KiB) 82-mal heruntergeladen
Benutzeravatar
Nanobot
Beiträge: 134
Registriert: Do 21. Feb 2019, 20:26
Box: Zgemma H7C, Coolstream Zee

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Nanobot »

Jepp, es geht mir darum, daß die providerseitig definierten Bouquets, welche während des Suchlaufes erzeugt werden, eben nicht mit [POS] geprefixt werden sollen. Bei einer Sat-Anlage mit Multifeed ist dieser Präfix natürlich sehr hilfreich. Bei einer Sat-Anlage mit Single-Feed oder Kabel ist sie dagegen überflüssig.

Der Prefix leitet sich übrigens nicht aus der cables.xml, sondern offenbar aus der services.xml ab, denn dort steht:
<cable name="Kabel Deutschland" position="3841">
Wie diese Positionsangabe in die services.xml gelangt, ist mir allerdings unklar, denn in der cables.xml gibt es keine Positionsangabe.

Und eine eigene aktuelle cables.xml für Kabel Deutschland / Vodafone in Berlin habe ich natürlich:

Code: Alles auswählen

<?xml version="1.0" encoding="iso-8859-1"?>
<cables>
	<cable name="Kabel Deutschland" satfeed="true" flags="9">
		<transponder frequency="122000" symbol_rate="6900000" fec_inner="0" modulation="3"/>
		<transponder frequency="330000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="338000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="346000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="354000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="362000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="370000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="378000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="386000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="394000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="402000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="410000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="418000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="426000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="434000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="442000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="450000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="458000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="466000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="474000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="482000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="490000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="498000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="522000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="530000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="538000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="546000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="554000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="562000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="570000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="578000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="586000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="594000" symbol_rate="6900000" fec_inner="0" modulation="5"/>
		<transponder frequency="610000" symbol_rate="6900000" fec_inner="0" modulation="3"/>
	</cable>
</cables>
Aber letztendlich habe ich, wie vanhofen schon korrekt erkannt hat, nur den Wunsch, den Prefix auf irgendeine Art und Weise deaktivieren zu können.

@Janus
Deinen Patch für die providermap.xml finde ich sehr gut. Mir gefällt nicht nur dir Möglichkeit, die verschiedenen Radiobouquets der ARD zu einem gemeinsamen Bouquet zusammen zu fassen. Vielmehr könnte kann man dies ja sogar nutzen, um die Prefixe loszuwerden, in dem man zum Beispiel solch einen Eintrag erstellt:

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>
<zapit api="4">
  <BC bcID="3841">
    <TS name="[C384.1] ARD" newname="ARD"/>
  </BC>
</zapit>
Mal sehen, ob dein Patch einen Weg in das offizielle Image findet.
Zgemma H7C NI 4.00.95, NI 4.10.105.119, BPanther 19746, BPanther 19860
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Janus »

Prefix leitet sich übrigens nicht aus der cables.xml, sondern offenbar aus der services.xml ab
Der leitet sich sehr wohl aus der cables.xml ab.
Die BCIDs im Satbereich errechnen sich aus dem Wert für die Position (umgerechnet in HexWerte von 0x0 bis 0xE10)
In Neutrino wird dann aus dem Folgewert (0xE10) als Basis und dem Offset anhand der Stellung des Sendemastes in der terrestrial.xml eine entsprechende BCID konstruiert.
Das gleiche Verfahren wird auch für die Kabelprovider angewendet (wenn man das nicht überschreibt)
Basiswert ist da 0xF00 und der Offset ist die Nummer des Providers in der cables.xml.

Da ich nur einen Provider da stehen habe, ergibt sich bei mir (automatisch) 0xF01.
Das Ganze ist zwar willkürlich, aber mit 'Überlegung' in NeutrinoHD eingeführt worden.
könnte kann man dies ja sogar nutzen, um die Prefixe loszuwerden
Das glaube ich eher nicht. Dazu müsste man in die Sourcen eingreifen. Zu sehen ist die Stelle in dem Patch für die Umstellung auf "C" und "T"....
Benutzeravatar
Don de Deckelwech
NI - Team
Beiträge: 1586
Registriert: Di 12. Apr 2016, 17:13
Wohnort: Wuppertal
Box: Tank / HD51 / Protek 4K für Kabel
Been thanked: 5 times
Kontaktdaten:

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Don de Deckelwech »

Hi,
benutze doch einfach eine ubouquets.xml, da kannst du deine Bouquets nennen (und auch sortieren), wie du willst. ;)
Das ist sowieso anzuraten, denn an den vom Suchlauf (jedes mal neu) erstellten services.xml bzw bouquets.xml, soll man eh die Finger lassen...

Ciao,
DdD.
"Ein Log, ist besser als kein Log!"
Benutzeravatar
Nanobot
Beiträge: 134
Registriert: Do 21. Feb 2019, 20:26
Box: Zgemma H7C, Coolstream Zee

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Nanobot »

Die ubouquets.xml benutze ich ja ohnehin, wobei ich dort aber nur die wirklich oft genutzen Sender aufnehme. Wenn ich nun ausnahmsweise doch einmal einen Sender sehen möchte der nicht in meiner ubouquets.xml enthalten ist, greife ich auf die providerdefinierten Bouquets zurück. Und die Tatsache, daß dort jetzt beim NI der Positionsprefix davor steht, nervt mich etwas. Man könnte natürlich auch zurecht sagen, daß ich ein Luxusproblem habe. :-)
Zgemma H7C NI 4.00.95, NI 4.10.105.119, BPanther 19746, BPanther 19860
Benutzeravatar
annie
NI - Team
Beiträge: 1010
Registriert: Di 5. Apr 2016, 18:46
Wohnort: zuhause
Box: 1x E4HD, 4x HD51,1x VuUno4K

Re: [384.1] vor Providername nach Suchlauf

Beitrag von annie »

wenn mich das so stören würde in der bouquets.xml, würde ich einen Editor nehmen und die Funktionen suchen/ersetzen anwenden.
Benutzeravatar
Nanobot
Beiträge: 134
Registriert: Do 21. Feb 2019, 20:26
Box: Zgemma H7C, Coolstream Zee

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Nanobot »

Das ist soweit richtig, aber nach einem Suchlauf wären diese Änderungen dann ja wieder weg .
Zgemma H7C NI 4.00.95, NI 4.10.105.119, BPanther 19746, BPanther 19860
Benutzeravatar
TangoCash
NI - VIP
Beiträge: 447
Registriert: Di 12. Apr 2016, 20:18
Box: Mutant HD51
Kontaktdaten:

Re: [384.1] vor Providername nach Suchlauf

Beitrag von TangoCash »

Also die Zahlen kommen von hier: https://github.com/neutrino-images/ni-n ... s.cpp#L911

Hintergrund:
Neutrino kann nur mit "Sat-Positionen" umgehen, zum finden der Transponder auf dem richtigen "Satelliten"
Und wer in der Schule aufgepasst hat, gehen die Positionen eines Kreises von 0-360, also werden C und T Sender einfach hinten angehangen:
https://github.com/neutrino-images/ni-n ... s.cpp#L944 (0xE11 = 3601)
https://github.com/neutrino-images/ni-n ... s.cpp#L949 (0xF01 = 3841)

Diese werden dann mit abgespeichert (services.xml), und später beim einlesen wieder zugewiesen.
Es gibt genau 10 Sorten von Leuten – nämlich diejenigen, die das binäre System verstehen, und diejenigen, die es nicht tun.

4x Mutant HD51
1x VU+ Ultimo 4k
1x Edision Mio+ 4k
1x Mutant HD60
Benutzeravatar
Nanobot
Beiträge: 134
Registriert: Do 21. Feb 2019, 20:26
Box: Zgemma H7C, Coolstream Zee

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Nanobot »

Ich werde also vorerst den Prefix einfach nach jedem Suchlauf per Texteditor entfernen lassen, denn extra deshalb einen Patch entwickeln und selber kompilieren übersteigt dann doch meine Kenntnisse. Ich würde mich aber freuen, wenn meine Anregung, den Prefix abschaltbar zu machen, irgendwann einmal realisiert werden würde.
Zgemma H7C NI 4.00.95, NI 4.10.105.119, BPanther 19746, BPanther 19860
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: [384.1] vor Providername nach Suchlauf

Beitrag von Janus »

Neutrino kann nur mit "Sat-Positionen" umgehen
Na ja, so ganz stimmt das nicht.
Da bei der damaligen "Übersetzung" von BetaResearch-Firmware der DBox in OpenSource-Neutrino maximal zwei Satpositionen - oder nur ein Kabelnetzbetreiber - zu berücksichtigen waren, war das einzig notwendige Unterscheidungskriterium die Position der beiden Satelliten.

Der Begriff Broadcaster-ID aus den DVB-Papers wurde damals genausowenig berücksichtigt, wie die korrekte Transportstream-Adressierung bcID > onID > tsID.
Das wurde erst Jahre später 'weiterentwickelt', als mit richtigem DiSEqC der Zugriff auf mehrere Satpositionen möglich wurde und dabei mit der alten Version schlicht Sender nicht mehr gefunden wurden, weil die ursprüngliche Mini-ServiceID nicht mehr eindeutig war.

Und mit dem modernen Multituner-Equipment tauchte auch die Frage nach einer Broadcaster-ID - für andere Delivery-Systeme - wieder auf. Da sich die Satposition bei DVB-S schon als bcID bewährt hatte, ist man hingegangen und hat den möglichen Zahlenraum entsprechend hintenheraus 'bündig' erweitert. Andere Systeme, z.B. die .ini-Gemeinde setzen dabei auf dezimale Unterscheidungen: Satpos > 4000 > 5000 usw. weil trotz DVB-Vorgaben meist keine automtisiert auslesbaren bcIDs in den SI-Daten sind.

Der einzig wirkliche Fehler von Neutrino besteht darin, den ürsprünglich von BR 'übernommenen' Variablen- und Attributbezeichner "position" bei der korrekten Weiterentwicklung nicht in "bcid" zu ändern.
Hätte ja Arbeit gemacht. Und wäre vielleicht nicht abwärtskompatibel gewesen. So ist OpenSource halt.

Aber abgesehen davon, würde eine Abschalt-Option für's Prefix in Userhand Sinn machen. Wer nach der Abschaltung feststellt, das die Settingspflege komplizierter wird, kann es wieder einschalten.

Und wer in neutrino.conf per

Code: Alles auswählen

infobar_show_channeldesc=true
den Providernamen hinter den Sendernamen schreiben lässt, sieht das Prefix in der Infobar auch jetzt schon nicht.
Es gibt also schon irgendwo eine Stelle im Source, wo das wieder weggenommen wird.

Keine Ahnung, ob das mit Logos statt Namen auch funktioniert. Ich kürze neben meinen Providernamen auch meine Sendernamen über un="wie's mir gefällt" in ubouquets.xml. Das verhindert zudem auch noch die dämlichen Recycling-Umbenennungen durch Sky und Konsorten...
Antworten

Zurück zu „Nevis (HD1, BSE, NEO, NEO², ZEE)“