Einige Kanäle werden mit w_scan bei redirect für Cine CT nicht gefunden [war: w_scan + VDR fügen ORF eins HD nicht in channels.conf ein (DVB-C Liwest)]

  • Hallo und schönen guten Morgen,


    ich betreibe yaVDR 0.5.0a 64bit als headless-VDR in einer KVM virtuellen Maschine mit einer Digital Devices Cine CT 6 (V6.1 lt. dmsg) + CI an TAB 2 und habe anfänglich die channels.conf-Datei für Liwest (AT/Linz) aus dem vdr-wiki (http://www.vdr-wiki.de/wiki/in….conf_DVBC-At-Linz-Liwest) verwendet. Als Client komt XBMC 12.2 unter Windows und VNSI zum Einsatz. Im großen und ganzen funktioniert dieses Setup auch. Aber in dieser channels.conf-Datei fehlen der Sender »ORF eins HD« und ein paar Radiosender bereits. Laut Liwest und meinem TechniSat Receiver liegt der »ORF eins HD« auf 394MHz. Am Receiver, an einer anderen CATV-Enddose mit separatem Kabel vom CATV-Verteiler, ist der Empfang kein Problem.


    Da der VDR, bei entsprechendem Setup, neue gefundene Sender automatisch in die channels.conf einfügt, habe ich einfach einige Tage gewartet, damit dieser die fehlenden Sender hinzufügen kann. Jedoch passierte das selbst nach über einer Woche dauerbetrieb nicht; andere Sender wurden jedoch in der Liste ergänzt oder umbenannt. Daher habe ich einen Suchlauf per »w_scan« gestartet. Jedoch fehlt auch hier der Sender»ORF eins HD«. Um dem Problem auf die Schliche zu kommen habe ich dann noch folgendes probiert:


    Code
    # w_scan -v -v -fc -cAT -o7 &> test.txt


    Dabei habe ich folgnedes rausgefunden:



    Hier wird im ersten Scandurchlauf bei 394MHz eine Liste von verwendeten Transpondern übertragen, die Liwest verwendet. Wobei ich nicht weiß, was genau »undefined outer fec« und »undefined inner fec« zu beduten haben.


    Dannach beginnt der zweite Scandurchlauf von w_scan und spuckt folgendes aus:



    Der Sender »ORF eins HD« und auch andere werden hier als Service gefunden. Jedoch ist hier interessant zu sehen das die PAT eine Länge von -2 hat. Auf anderen Transpondern mit TV-Sendern ist die PAT nicht leer und es gibt auch Daten der PMT, wie unten zu sehen ist. Und obwohl das Service gefunden wird, wird es nicht in die channels.conf übertragen. Ich vermute mal wegen nicht gefundener PIDs für das Service.



    Woran kann es liegen, dass »ORF eins HD« nicht in die channels.conf aufgenommen wird und wie kann ich das Problem lösen? Ich gehe jetzt nicht von einem Hardwareproblem meinerseits aus, da auch bereits die channels.conf vom VDR-Wiki ORF eins HD nicht beinhaltet. Kann es sein, dass der Transportstrom für den Transponder auf 394MHz nicht ganz in Ordnung ist?


    Danke schonmal für's bis hier her lesen. Ist wegen dem Log etwas länger geworden.


    MfG
    Günther

    Einmal editiert, zuletzt von thedon () aus folgendem Grund: Titel beschreibt das Problem nicht.

  • Hallo,


    ich hab jetzt die DVB-C Karte Cine CT V6 in einen anderen PC gesteckt und dort yaVDR 0.5.0a + linux-media-dkms zum Testen installiert. Dabei haben erste Tests gezeigt, dass die Anzahl der Service die w_scan findet davon abhängt ob ich

    Code
    options ddbridge adapter_alloc=3

    in /etc/modprobe.d/ddbridge.conf und

    Code
    echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect

    aktiviert habe oder nicht.

  • Tatsächlich hat sich die Vermutung bestätigt, dass es mit den Treiberoptionen für die Cine CT zusammenhängt.


    Ich habe mit folgendem Befehl getestet

    Code
    # w_scan -fc -cAT -o7 -Q1 -S0 -a /dev/dvb/<adapter>/<frontent> | sort > file.txt


    -) Wurden weder die Moduloption adapter_alloc=3 noch redirect gesetzt, kann ich auf den Tunern /dev/dvb/adapter0/frontent0 und /dev/adapter1/frontent0 einen ordentlichen Scan durchführen und bekomme auch 392 Kanäle inkl ORF eins HD, um den es ursprünglich ging.


    -) Wurde nur die Moduloption adapter_alloc=3 gesetzt aber kein redirect, so kann ich auf dem Tuner /dev/dvb/adapter0/frontent0 einen ordentlichen Scan durchführen und bekomme auch fast alle (>390) Kanäle rein. Führe ich einen Scan auf /dev/dvb/adapter0/frontent1 durch, werden gar keine Kanäle gefunden.


    -) Wurde sowohl Moduloption adapter_alloc=3 als auch das redirect gesetzt, kann ich auf dem Tuner /dev/dvb/adapter0/frontent0 einen Scan durchführen; bekomme aber jedesmal eine ganz unterschiedliche Anzahl von Kanälen wobei viele dann nur mit "service_id...." betitelt sind. Ein Scan auf Tuner /dev/dvb/adapter0/frontent1 findet wie oben keine Kanäle.


    Mit "Kanäle finden" meine ich die Anzahl der Zeilen die w_scan am ende ausgibt [dumping services (x)].


    Eine Lösung für das Problem habe ich aber noch nicht.

  • Ich wollte eigentlich nicht antworten (ja, warum mache ich das?), aber Selbstgespräche sind ja auch nicht der Weisheit letzter Schluss ;). Irgendwie wirst du ignoriert. Kann aber auch daran liegen, dass der weltweit einzig verfügbare Treiber/Firmwareentwickler für DD-Produkte unter Linux gerade Urlaub hat - der müsste eigentlich wissen, was gehauen und gestochen ist.

  • Hi,


    da es sich um ein Phänomen handelt, dass einem unter Umständen nicht gleich auffällt ist das nicht verwunderlich. Außerdem ist es IMHO im falschen Subforum, weil ich eher als Fehlerursache meinen Kabelprovider Liwest in Verdacht hatte. Das es am Redirect liegen könnte hätte ich ehrlich gesagt nicht gedacht.


    Ich hab jetzt w_scan mit redirect aber ohne eingestecktem CAM (Technisat TechniCrypt CX) durchgeführt, aber mit dem gleichen Ergebnis wie mit redirect und mit CAM.


    Zitat


    Kann aber auch daran liegen, dass der weltweit einzig verfügbare Treiber/Firmwareentwickler für DD-Produkte unter Linux gerade Urlaub hat.


    Der Urlaub sei der besagten Person gegönnt. Ich hoffe dieser bringt auch Erholung.

  • Moin!


    Vielleicht ist es ja nur ein Problem beim Scannen, weil da sehr häufig umgeschaltet wird.
    Auch ohne redirect melden die CineCT beim Epgscan gerne mal "lost lock". Das hat aber keinen Einfluss auf den normalen Gebrauch.


    Lars.

  • Zitat


    Vielleicht ist es ja nur ein Problem beim Scannen, weil da sehr häufig umgeschaltet wird.


    Naja, aber ein Scanvorgang ohne redirect schaltet genau so häufig und schnell um, wie mit redirect. Also daran *alleine* kann es auch nicht liegen, aber ich habe auch den (ersten) eindruck, dass das Schauen besser klappt als Suchen. Könnte allerdings mit der zusätzlichen Verarbeitung die fürs CI (und CAM) bei redirect nötig ist, zusammen hängen.


    ORF eins HD liegt am ersten Transponder (d.h. der Transponder mit der niedrigsten Frequenz bei 394 MHz) und den hab ich bei keinem Scanvorgang mit redirect als Kanal gefunden.

  • ohne "redirect":
    Für w_scan sollte es keinen Unterschied machen, ob man adapter_alloc verwendet oder nicht. Zufall?


    mit "redirect":
    Das CI/CAM bedeutet zusätzliche Pufferung und eine gewisse Verzögerung. Wenn sich das Scannen knapp an der Timeout-Grenze bewegt, könnte ich mir vorstellen, daß es einen Unterschied macht. Wie sieht es aus, wenn man w_scan zusätzlich die Parameter "-F -t 3" mitgibt?


    CU
    Oliver


  • mit "redirect":
    Das CI/CAM bedeutet zusätzliche Pufferung und eine gewisse Verzögerung. Wenn sich das Scannen knapp an der Timeout-Grenze bewegt, könnte ich mir vorstellen, daß es einen Unterschied macht. Wie sieht es aus, wenn man w_scan zusätzlich die Parameter "-F -t 3" mitgibt?


    Ich hab mir den Sourcecode der Version 2013-03-31 von w_scan geholt (w_scan) und wie folgt geändert:


    Ausgabe von diff:


    Zeile 1608c: Längeres Timeout beim Warten auf POLL-Ereignisse
    Zeile 2803c, 2871a,3095a: Keine neuen Transponder, die während eines Inital-Scan gefunden wurden, hinzufügen. Damit ich nicht immer das ganze Spektrum absuchen muss, sondern nur einige Testtransponder, sonst dauert dieser immer eine Stunde.


    Ich habe zwei Datein mit Inital-Scan-Daten.
    liwest.it mit 3 Transpondern

    Code
    # C[2] <freq> <sr> <fec> <mod> [# comment]
    #------------------------------------------------------------------------------
    C 394000000 6900000 AUTO   QAM256       # LIWEST
    C 714000000 6900000 AUTO   QAM256       # LIWEST
    C 722000000 6900000 AUTO   QAM256       # LIWEST


    und orf.it mit einem Transponder

    Code
    # C[2] <freq> <sr> <fec> <mod> [# comment]
    #------------------------------------------------------------------------------
    C 394000000 6900000 AUTO   QAM256       # LIWEST


    Starte ich meine gepatchte Version von w_scan mit orf.it, dann findet es immer die 11 darauf laufenden Services (Radio, SD unverschlüsselt, ein HD verschlüsselt). Das funktioniert auch, wenn ich zuvor ein
    w_scan mit liwest.it laufen ließ.

    Code
    ./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontent0 -I orf.it


    Starte ich hingegen meine gepatchte Version von w_scan mit liwest.it, dann wird bei jedem lauf eine andere Anzahl an Services erkannt (7-26 Stück). Dabei lässt sich auch kein Zusammenhang mit dem Transponder herstellen. Wobei ab und zu "Info: no data from PMT" ausgegeben wird, dass mir beim Scan mit orf.it noch nicht aufgefallen ist und einie Kanäle werden nur mit "service_id x" erkannt.

    Code
    ./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontent0 -I orf.it


    Wirkt sich ein eingestecktes CAM bei der CI erweiterung für die Cine CT V6 auch auf das Tuning-Timing aus? Oder anders gefragt, sollte ich andere Ergenisse erwarten, wenn ich kein CAM eingesteckt aber redirect aktiviert habe und bringt mich so ein Test überhaupt weiter?



    EDIT (Hinzugefügt): Also -F -t 3 löst das Problem auch nicht. Wenn es ein Timingproblem ist (von dem ich mittlerweile auch stark ausgehe) dann ist das nicht *knapp* an irgend welchen Grenzen.

  • ohne "redirect":
    Für w_scan sollte es keinen Unterschied machen, ob man adapter_alloc verwendet oder nicht. Zufall?


    Bei mir verhält sich w_scan ohne redirect deterministisch.


    Ist adapter_alloc=3 *nicht aktiv* und scanne ich Tuner 0 mit

    Code
    ./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontend0 -I ~/liwest.it


    oder Tuner 1 mit

    Code
    ./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter1/frontend0 -I ~/liwest.it


    liefert mir w_scan immer ordentliche 36 Kanäle. Auch dann, wenn ich die Parameter -F und -t 3 weglasse.


    Ist adapter_alloc=3 *aktiv* und scann ich Tuner 0 mit

    Code
    ./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontend0 -I ~/liwest.it


    so bekomme ich 36 ordentliche Kanäle. Scanne ich jedoch Tuner 1 mit

    Code
    ./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontend1 -I ~/liwest.it


    Werden keine Kanäle gefunden und er schreibt
    "Info: no data from PAT"
    "Info: no data from SDT(actual)"
    "Info: no data from NIT(actual)" pro Transponder.


    Das Tuning dürfte aber funktionieren, weil ich auch bei frontend1 ein "signal ok" bekomme.


  • Dies ist ein Bug in w_scan:
    Lt. Code wird immer demux=0 verwendet. So kann das nicht funktionieren. Es muß der zugehörige Demux geöffnet werden. Richtig wäre also demux=1 bei frontend=1.


    CU
    Oliver

  • Wo genau steht in der DVB API die Zuordnung frontend <-> demux falls mehrere frontends auf einem device sind?
    Ist das ein common agreement bei den DVB developern, dass jede(wirklich jede!) dvb hw mit mehreren frontends mehrere demux devices hat, je eines per frontend?


    In der Vergangenheit gabe zu solchen Fragen nie echte Klarheit, wie solche hardware zu handeln ist.


    Falls ja, würde ich mich über einen patch freuen.

  • Moin!


    So 100% ist die DVB-Spec nicht, aber der vdr behandelt die Devices so und anscheinend machen es auch alle Treiber so:
    http://linuxtv.org/downloads/v4l-dvb-apis/dvb_devices.html
    Da das "M" hinten dran bei allen Devices gleich ist, sollte man es auch immer gleich haben.


    Ich würde so vorgehen, dass erst mal ein demux mit der gleichen Nummer probiert wird, und wenn das nicht da ist, dann heruntergezählt wird, bis man bei 0 angelangt ist.


    In der Vergangenheit war es bei Hybridgeräten (z.B. DVB-S + -T) immer ein wenig merkwürdig, da hat jeder gemacht, was er wollte, weil die Spec das nicht abgedeckt hat.
    Fakt ist aber, dass das einer der weißen Flecken auf der DVB-Karte ist.


    Lars.


  • Das mit der Nicht-Eindeutigkeit ist genau der Grund, warum dieses Problem auftritt. Probieren und Raten ist IMHO hier keine Option.

  • Moin!


    Da sind wir einer Meinung. Ich kenne allerdings keinen DVB-Treiber, bei dem frontendN mit demuxM zusammenarbeitet.
    Hast du ein Beispiel?


    Lars.

  • Ich kenne doch nicht alle dvb karten.


    Ich frage stattdessen nach einer lesbaren Spec, die diesen Punkt enthält.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!