t2scan: neues DVB-T/T2 Channel Scan Tool basierend auf w_scan

  • Achso, clausmuus : Falls die neue GIT-Version bei dir immer noch nicht zuverlässig klappt, schick mir bitte mal ein Scan mit Debug-Ausgabe zu (ein "-v" müsste hier schon reichen, da sieht schon ob überhaupt ein Carrier gefunden wird, ob es ein Lock gibt, und ob er die NIT scannt). Am besten beschänkst du den Scan mit "-l" auf die Kanäle, auf denen auch Services drauf sind. Sonst wird das Log doch arg lang.

  • Ich habs kurz getestet und würde sagen es passt.

    Bei Aufruf mit

    gentoo64vdr ~/down/t2scan-master # ./t2scan -t 2

    wird die PLP 1 für AT verwendet.


    Scandauer 3:30 min, dabei 7 Transponder gefunden, 2 weitere mit 11 sec. PAT timeout. (findet alle vorhandnen 6 MUXe + einen auf einer zweiten Frequenz noch einmal)

    Die Version vom 29.April 2018 braucht 3:13min, ebenfalls 7 Transponder gefunden und 2 mit 2 sec PAT timeout.


    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Danke. Das sieht doch gut aus. Die 17 Sekunden längere Scan-Dauer liegt an dem 2 sec vs. 11 sec PAT-Timeout (also der Veränderung des Filter-Timeouts). Das Szenario ist hier, dass etwas empfangen wird, aber dann der Empfang doch nicht gut genug ist, um die Sender wirklich einzulesen. Da dieses Szenario normalerweise nur einige wenige Kanäle betrifft, kann man mit dem längeren Timeout, glaube ich, leben.

  • So, ich konnte das jetzt auch testen. Jetzt wurden bei den drei bisher durchgeführten Scans die selben Kanäle gefunden, und obendrein erheblich mehr als bei allen zuvor durchgeführten Scans zusammen :)

    Die Scan Dauer hat sich hingegen nur um 10 Sekunden (von 1:30 auf 1:40) verlängert.


    Alles in allem also ein voller Erfolg!

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Das hört sich sehr gut an. Danke für's Testen. Hast du jetzt eigentlich den Parameter "-S" benutzt (wenn ja, mit welchem Wert?), oder geht es ohne?

    Ganz interessant für mich wäre noch, wenn du ein Log mit der *alten* Version von t2scan (also 0.4) machen könntest, dann kann ich besser verstehen, welche Änderung die Probleme beseitigt hat. Es reicht dabei, wenn der Log auf die Kanäle beschränkt wird, die du empfangen kannst, also etwa "t2scan -vv -l <kanalliste> 2>debuglog.txt". Das Debug-Log dann bitte per PM an mich. Danke!

  • Das war ohne -S Option. (Übrigens steht in der Hilfe (--help) nichts von der Option)..

    Ich habe die Scans mit -t2 durchgeführt.


    So, und jetzt die schlechte Nachricht. Der Vierte Scan hatte nichts gefunden. Hier die ausgiebigen Meldungen eines erfolglosen Scans eines Kanals:

    Und hier der Selbe Scan wenn er erfolgreich ist:

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Die -S Option steht nur in der Expertenhilfe ("-H").


    Danke für die Logs. Der Unterschied zwischen dem erfolgreichen und dem nicht erfolgreichen Durchlauf ist, dass beim nicht erfolgreichen Durchlauf innerhalb des Carrier-Timeouts kein Carrier (also kein Signal) gefunden wird. Das Default-Timeout ist hierfür ja 2 Sekunden, d.h. innerhalb dieser wurde kein Carrier gefunden. Man kann den Timeout jetzt mal mit "-S 2" zum Beispiel verdoppelt werden (oder mit "-S 3" gar verdreifacht). Nur ob das hilft? Gerne mal probieren, aber was auffällt ist, dass beim erfolgreichen Durchlauf bereits nach 150ms der Carrier gefunden und nach 410ms gelockt war.Trotzdem bitte mal "-S2" und "-S3" probieren, ob das verlässlich hilft. Allerdings befürchte ich hier ein irgendwie geartetes anderes Tuning-Problem, wo ich noch gar keine Idee habe, was das sein könnte. Bei allen Testläufen bitte "-v 1" als Parameter drin lassen.

  • clausmuus Sorry dass ich nochmal nerve. Ich hab ins GIT zusätzlichen Debug-Code zum Tuning-Prozess eingefügt, der ausgegeben wird, wenn mindestens "-v 1" benutzt wird. Wenn du damit nochmal einen nicht erfolgreichen Tuning-Versuch loggen könntest, wäre das möglicherweise hilfreich.

  • Mit -S2 und -S3 hatte ich auch probiert, mit dem einzigen Unterschied, das es länger dauert. Das hatte also auch nicht geholfen.

    Hier jetzt die Log Ausgabe mit den neuen Sourcen:

    Und hier zum Vergleich der Erfolgreiche Scan:

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Was ich nicht verstehe: Eigentlich müsste beim nicht erfolgreichen Durchlauf die Debugmeldung mit den Signalinfos viel öfter kommen (etwa 40x, da ja 50ms usleep gemacht wird in der Schleife und der Timeout 2 Sekunden ist). Hast du das Log gekürzt, oder kam das exakt genau so raus?

  • Das ist das vollständige Log.

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Ok, ich hab jetzt mal als letzte Amtshandlung den Tuning-Code etwas umgebaut, dort auch mehr Logging eingebaut, und ins GIT geladen. Bitte damit gerne nochmal probieren und Log über fehlgeschlagenen Durchlauf posten. Ich mache dann morgen Abend weiter.

  • Wenn ich optimiert Kompiliere (mit -O 3), dann gibt es die Meldung "signal e660 | snr 94a0 | ber 00000000 | unc 00000000 |" nur zwei mal. Der etwas schneller laufende Code gibt also nur zweimal die Logmeldung aus.

    Ich habe das mindestens 10 mal verifiziert.

    Die erweiterten Logs folgen gleich, und danach geht's auch für mich ab ins Bett :)

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • So, hier noch eben das Log:

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Danke. Da ist leider auch nichts besonderes zu sehen. Die Fehlermeldung auf Zeile 42 kommt bei mir auch, ich glaube diesen Cache-Clear-Befehl kann ich ganz aus der Befehlssequenz rausnehmen... Muss mir Gedanken machen, was da schief gehen könnte.

  • Wenn es Dir hilft, könnte ich Dir Zugang auf meinen RPI (mit dem DVB Reciver) mit einem Raspbian geben.

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Das würde wahrscheinlich schon helfen, um die Sache besser debuggen zu können (auch wenn ich natürlich nichts versprechen kann). Nur um die Erwartungen richtig zu setzen, ich werde möglicherweise erst am Wochenende wieder dazu kommen, mich wirklich länger mit der Sache zu beschäftigen.

  • Sag mir Bescheid, wenn ich den RPI am Wochenende mit Raspbian starten soll.

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Mache ich. Inzwischen mach ich mir ein paar Gedanken, wo das Problem sein könnte. Ich hab auch schon den ersten neuen Ansatz und vermute, dass möglicherweise deine Karte mit den ganzen AUTO-Settings beim Tunen nicht klar kommt (Inversion, Coderate/FEC, Modulation, Transmission, Guard und Hierarchy werden ja beim Tunen alle auf AUTO gesetzt). Beim VDR hat es der Tuner natürlich dann leichter weil in der erzeugten channel.conf dann ja die gefundenen Werte (z.B. Modulation=Qam64, Guard=1/4 usw.) drin stehen. Ob es das ist, muss ich dann aber wirklich am Wochenende ausprobieren.

Jetzt mitmachen!

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