Hi,

also je nach dem wie aktuell enigma2 ist (da ist nen bug im code) musst die python datei in /etc/enigma2 .. oder in /etc liegen.. in aktuellen experimental direkt in /etc .. weil das wie gesagt nen bug ist..

Die Datei selber wird dann ausgeführt für jeden neuen Transponder der bei der kanalsuche gefunden wird. Das tut exakt dasselbe wie der c++ code.

Sprich es soll geprüft werden, ob die TSID / ONID / ORBPOS kombination eindeutig ist.. oder ob der Provider mist gebaut hat, und den Muxxer falsch geconfed hat. Beispiele dafür gibts ja in der scan.cpp genügend.

Und zu der Frage von oben.. nein es ist nicht gut die Orbital position zu ignorieren und einfach alle möglichen Kombinationen Global blackzulisten.

Von dem Ergebniss der Prüfung hängt ab, wie enigma2 den DVB Namespace zusammenbaut. Bei Transpondern die okay sind, ist das dann einfach nur die Orbital Position. Bei kaputten wird da aber noch mehr eingeflochten.. die Polarisation, die Frequenz.. usw..

Damit Transponderlisten aber zwischen mehreren Boxen austauschbar bleiben, sollte halt die Regel sein, dass die Transponder korrekt sind.. und nicht die Frequenz usw mit einfliesst.. weil das wiederrum vom verwendeten LNB / der satellites.xml abhängen kann.

Naja wie dem auch sei.. man sollte auf keinen Fall das tun, was du getan hast.

Soo nun schnell noch nen Beispielt, wie die Datei aussehen könnte. Also die python datei.

Ich mach mal als Beispiel nun das, was die C++ schon prüft.

Also folgendes die Datei selber bekommt 3 Variablen übergeben.. bei jedem Aufruf.. das ist "orbpos", "tsid", "onid". Diese kann man da einfach benutzen. Das Ergebniss muss in "ret" gespeichert werden.

Folgender Teil aus dem C++ code:

case 42: // Tuerksat 42.0E
                ret = orbital_position != 420 || (
                    tsid != 8 && // 11830V 12729V
                    tsid != 5 && // 12679V 12685H
                    tsid != 2 && // 11096V 12015H
                    tsid != 55); // 11996V 11716V
                break;
        case 100: // Intelsat 10 68.5E 3808V 3796V 4012V, Amos 4.0W 10723V 11571H
                ret = (orbital_position != 685 && orbital_position != 3560) || tsid != 1;
                break;

Könnte in der /etc/.../scan_tp_valid_check.py so aussehen:

if onid == 42: #Tuerksat 42.0E
    ret = orb_pos != 420 or (tsid != 8 and tsid != 5 and tsid != 2 and tsid != 55)
elif onid == 100: #Intelsat 10 68.5E 3808V 3796V 4012V, Amos 4.0W 10723V 11571H
    ret = (orb_pos != 685 and orb_pos != 3560) or tsid != 1
else:
    ret = 1

Da wird halt einfach ein "wahrheitswert" gebildet... um zu erreichen, dass alle Transponder als "feeds" angesehen werden, würde es schon reichen in der datei nur "

ret=0

zu schreiben... aber das ist wie gesagt nicht so vorteilhaft.

cu

Hi,

häng mir mal bitte die Liste der doppelten Transponder an, die Du als Grundlage für deine bauerei da genommen hast.

Irgendwie sieht mir das Ergebniss da nicht richtig aus.

cu

Hi,

also naja.. bei onid 0 und 1 kann man sich den ganzen orbital position check schenken 0 ist immer kaputt also es gibt nirgends transponder wo eine ONID 0 korrekt wäre.

ONID 1 ist nur auf astra 19.2 valid.. es gibt da eine liste irgendwo .. oder gabs mal.. und die ONID 1 ist eine anbieter auf astra 19.2. sprich auf allen anderen satelliten ist das eh kaputt.

Deshalb waren die defaults in der standard scan.cpp da halt schöner.

und die 65535 ist auch generell kaputt.. die wurde aber über den default zweig schon gehandled mit dem ret = onid.get() < 0xFF00. Soll heissen alle onids > 65280 sind ebenfalls generell kaputt.. also kann man sich da auch die ganzen orbital positions prüfen schenken.

ONID 2 gibts nur auf Astra 28.2 .. deshalb ist dieser check da auch drinn. mit der ausnahme dass es auf astra 28.2 selber zwei transponder gibt die die selbe TSID/ONID kombination haben.. was wiederrum nicht erlaubt ist.

Naja.. der standard deckt halt schon 99% von dem ab, was in deiner liste da drinn steht.. ist aber weniger code.. lässt sich aber schwer automatisch generieren.

cu