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

    mighty-p : Du solltest vielleicht in check_frontend() die fehlerfreie Ausführung der ioctl-Aufrufe prüfen (0). Irgendwie passen bei clausmuus die Signalwerte und der Status nicht zusammen.

    Edit:

    Ohne Signal oder Lock im Status-Flag sind die anderen Werte sicher nicht gültig, also besser dann nur das Statusflag anzeigen.

    Helmut

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

    Edited once, last by HelmutB † (January 8, 2019 at 1:23 AM).

    Ich konnte mir das Problem von clausmuus heute genauer ansehen.

    Folgendes passiert: Nach Öffnen des Frontends ist dieses manchmal in einem komischen Status. Tunen scheint zwar zu klappen, tut es aber nicht. Wenn man den Status per ioctl FE_READ_STATUS abruft, kriegt man dann auch immer schön ein -1 zurück, also den Fehlerstatus. Das wurde bis jetzt allerdings im Code komplett ignoriert :D

    Woran das Problem liegt, weiß ich nicht. Workaround in der aktuellen Fassung im GIT ist, dass ich jetzt ganz am Anfang schon einmal teste, ob FE_READ_STATUS erfolgreich ist. Wenn dies nicht ist, wird folgende Fehlermeldung ausgegeben und das Programm beendet (der Scan läuft also gar nicht erst los):

    Code
    main:2913: FATAL: FE_READ_STATUS failed: 11 Resource temporarily unavailable

    Man kann es dann nochmal probieren, bis es klappt.

    Wenn irgendjemand ne Idee hat, was da initial schief geht und wie man das Problem verhindert, dann lasst es mich wissen.

    Noch ganz interessant: Wenn man parallel (auf ner weiteren Konsole) femon laufen lässt - was interessanterweise immer funktioniert, also nicht diesen Fehler triggert - dann danach t2scan startet, dann scheint auch t2scan nie dieses Problem zu haben. Vielleicht hilft das ja beim Verstehen des Problems.

    Edit/Update: Ich glaub, ich hab den "root cause" gefunden. Wenn das so ist, dann erhält der aktuelle GIT-Stand auch schon ein Fix. Das Schließen und Wieder-Öffnen des Frontends im Autodetection.Code, bei dem getestet wird, welches Frontend denn zu benutzen ist, ging wohl zu schnell. Ich hab 500ms Pause dazwischen eingebaut und kann seither auf clausmuus' System das Problem nicht mehr reproduzieren.

    Edited once, last by mighty-p (January 13, 2019 at 7:49 PM).

    Die Verbesserungen an t2scan gehen weiter und es gibt mehrere Updates im GIT. Das Problem mit clausmuus' Karte "TurboSight TBS 5520SE DVB-T/T2/C/C2/ISDB-T" sollte behoben sein ( clausmuus falls es doch nochmal Probleme gibt, melde dich einfach).

    Das Problem hat mir wieder gezeigt, dass es nicht ganz unwichtig ist, mit verschiedener Hardware zu testen. Daher würde mich schon interessieren, mit welcher Hardware/Frontends t2scan bereits getestet wurde und ob es zuverlässig damit läuft oder nicht. Das benutzte Frontend wird ja von t2scan am Anfang angezeigt:

    /dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Silicon Labs Si2168": very good :-))

    Bis jetzt wissen wir, dass (inzwischen) folgende Frontends erfolgreich getestet wurden:

    - Silicon Labs Si2168 (wird z.B. in der von mir benutzten "DVBSky T9580 V3" verwendet, aber wohl auch in vielen anderen Karten)

    - TurboSight TBS 5520SE DVB-T/T2/C/C2/ISDB-T (Karte "TBS 5520 SE")

    Bitte gerne mit weiteren Karten testen und mir Rückmeldung geben (auch gerne über die Funktion "Konversationen"/PM, um diesen Thread nicht zu sehr zuzumüllen). Ich dokumentiere die Ergebnisse in der Datei TESTED_HARDWARE, die seit heute auch im GIT drin ist. Gerne auch melden, wenn es mit einer bestimmten Karte eben NICHT klappt.


    Dann noch ein Thema zu den erzeugten channel.conf Einträgen. Im Moment tuned t2scan ja mit fast allen Einstellungen auf AUTO (z. B. FEC_AUTO, TRANSMISSION_AUTO, QAM_AUTO, ...) und liest dann die genauen Kanal-Parameter aus der NIT. Das ergibt dann solche Ergebnisse wie

    Das Erste HD;ARD:562000:B8D0G19128S1T32Y0P0:T:27500:101=36:102=deu@17,103=mis@17:106:0:769:8468:21250:0

    Dieser channels.conf-Eintrag funktioniert bei mir auch einwandfrei in VDR, mit EPG und allem, was man so braucht :)

    Mein Gedanke ist allerdings, dass theoretisch ja in der NIT auch Blödsinn stehen kann. Damit hatten wir ja auch praktisch schon genug Probleme und es hat dazu geführt, dass Sender nicht gefunden wurden, und daher ignoriert ja t2scan auch schon vieles aus der NIT. Die Frage ist natürlich, ob die Kanalparameter in der NIT immer korrekt sind und ob inkorrekte Daten hier zu Tuning-Problemen führen würden. Und außerdem tunen die Frontends ja sowieso auch, wenn da fast alles im AUTO-Mode ist, sonst würde t2scan ja gar nichts finden.

    Daher hab ich jetzt zum Test einen undokumentierten Parameter -U drin, der dafür sorgt, dass die Kanaldaten nicht mit den Daten aus der NIT ausgelesen werden. t2scan -U ergibt demnach folgende Kanalzeile:

    Das Erste HD;ARD:562000:B8S1P0:T:27500:101=36:102=deu@17,103=mis@17:106:0:769:8468:21250:0

    Funktionieren tut die im VDR auch, auch EPG geht damit einwandfrei und ich kann keinen praktischen Unterschied im VDR sehen.

    Die Frage ist jetzt halt, "was besser ist". Also ob ich besser diese reduzierten Zeilen zum Standard von t2scan mache (und einen Parameter "-u" einführe, um das alte Verhalten zu aktivieren) oder es besser - auch auf die Gefahr dass die Daten in der NIT bei manchen Providern falsch sind - es so lasse wie es ist (weil entweder die Gefahr falsche Daten einzulesen gering ist, oder dies in der Praxis das Tuning sowieso nicht negativ beeinflussen würde).

    Wer kennt sich hierzu aus und was meint ihr?

    Um zu funktionieren müssen diese *_AUTO Parameter vom Frontend auch unterstützt werden.

    Für DVB-T habe ich nicht nachgesehen, aber für DVB-T2 gibt es in den Kernelquellen derzeit nur fünf verschiedene Frontends und alle können damit umgehen. Daher sollte bei einem Scan mit einer (und für eine) DVB-T2 Hardware die kurze Parameterangabe auch genügen (die AUTO-Parameter werden dann im Betrieb von VDR mit den Daten aus der NIT ersetzt).

    Für deine Hardwareliste: t2scan funktioniert auch mit meinem Astrometa DVB-T2 USB-Stick:

    /dev/dvb/adapter2/frontend1 -> TERRESTRIAL "Panasonic MN88473": very good :-))


    Helmut

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

    Hallo,

    Den Mygica t230 (alte Version) kann ich mal versuchen, habe aber schlechten Empfang mit Zimmerantenne.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    http://www.easy-vdr.de

    Geht auch mit:

    TT6400
    DVBSky S952

    Hi,

    Ich bin ja noch den Bericht schuldig.

    Ja der t2scan (git 29.1.19) läuft durch und findet auch Sender.

    Ich muss gestehen das ich durch die nicht hevc fähige Nvidia es nicht versucht habe ob es auch Bild gibt.

    Das mach ich gleich noch.

    Um es klarzustellen ; es geht um den alten Mygica t230 (Si2168) nicht den auch erhältlichen neueren. Der August soll baugleich zu meinem sein.

    Bandwith_auto not supported.

    Scan time 4:18.398

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    http://www.easy-vdr.de

    Edited 4 times, last by SurfaceCleanerZ (March 17, 2019 at 4:47 PM).

    mighty-p: danke für den t2scan :) es sollte manche grundsätzliche Probleme bei mir lösen.

    Ich habe die frische Version aus GIT kompiliert, gegen einem neuen 5.4.6 kernel.

    Ich habe 2 Stk. der Mygica "T230C v2" - frisch in 5.4 durch Treiber "dvbsky" unterstützt.

    Und, t2scan meldet einen Fehler schon im Anfang:

    Ich habe Ihren früheren Kommentar gelesen, daß "dieser Fehler in dem älteren w_scan ignoriert wurde". Das wahrscheinlich gilt noch. Trotzdem findet w_scan2 fast alle Kanäle. Also zum Vergleich:

    Ich habe alles aus Source Code übersetzt - ich wäre dankbar für jegliche Vorschläge, welche möglichen Änderungen zu testen.

    Das Country Code "CZ" macht keinen Unterschied, mit "DE" benehmen sich die beiden Programme ebenso.

    Frank

    Hallo frr,

    Interessant, dass es an der Stelle einen Fehler gibt.

    Wenn du die Zeile 2852 (mit dem "fatal") sowie auch die Zeile darüber (mit "cleanup()") in der Datei scan.c entfernst bzw. auskommentierst und dann neu kompilierst, funktioniert es dann?

    mighty-p: danke für die sofortige Antwort :) das war ja unglaublich...

    Ja, nach der vorgeschlagenen Änderung arbeitet es ganz gut:

    Ohne weiterer Suche, denke ich daß der Fehler eigentlich von dem dvbsky Treiber zurückgekehrt wird, oder?

    Quote

    mighty-p danke für die sofortige Antwort :) das war ja unglaublich...

    Das war einfach Glück. Ich war gerade am Computer und hab die Erwähnung direkt mitbekommen. Und da in der Fehlermeldung die Zeilennummer drin steht, war es nicht schwer schnell mal nachzuschauen, was in dieser Zeile denn gemacht wird :)

    Quote

    Ja, nach der vorgeschlagenen Änderung arbeitet es ganz gut:

    [...]

    Ohne weiterer Suche, denke ich daß der Fehler eigentlich von dem dvbsky Treiber zurückgekehrt wird, oder?

    Freut mich, dass es so läuft. Schon interessant, wie unterschiedlich sich die verschiedenen Karten teilweise verhalten. Wenn ich mich richtig erinnere, hab ich diesen Test mit dem FE_READ_STATUS eigentlich mit reingenommen, da bei einer anderen Karte teilweise das Frontend nicht richtig geöffnet wurde und immer wenn der Fehler auftaucht der Scan zwar scheinbar lief, aber keine Ergebnisse lieferte. Daher dachte ich: OK, wenn's hier schief geht, breche ich halt ab. Werde dann also demnächst die beiden Zeilen in der GIT-Version so ändern, dass zwar noch ein Fehler ausgegeben wird, aber das Programm weiter läuft.

    Quote from mighty-p

    Daher dachte ich: OK, wenn's hier schief geht, breche ich halt ab. Werde dann also demnächst die beiden Zeilen in der GIT-Version so ändern, dass zwar noch ein Fehler ausgegeben wird, aber das Programm weiter läuft.

    Danke :) Scheint mir wie ein annehmbarer workaround.

    Die bisherige Motivation hinter dem Code ist mir natürlich klar, ich bin selbst auf diese Weise behutsam wann ich etwas gelegentlich schreibe...

    Ich habe diesen Fehler bei ioctl(FE_READ_STATUS) in linux-media kurz off-topic bemerkt, aber da kann ich auf keine schnelle Lösung hoffen, die Maintainers sind beschäftigt. Wenn ich das selbst lösen würde und als ein Patch übermitteln würde, hätte ich eine Chance.

    Der t2scan hat bei mir wirklich in aller Ordnung durchgelaufen und auf "stdout" habe ich endlich komplette Ergebnisse erhalten - vielleicht zum ersten Mal aus der "w_scan Familie" :) Ich verwende es jetzt als meinen channels.conf. Ich habe die Ergebnisse in meiner vorgangenen Nachricht nicht eingeschlossen, weil die Nachricht schon über 10k Buchstaben war (und das Forum hat darüber geklagt).

    Noch ein Bisschen weiterer "Analüse":

    In dem Kernel auftaucht FE_READ_STATUS in drivers/media/dvb-core/dvb_frontend.cnatürlich in dem ioctl() hadler. Der Fehlerkode -EREMOTEIO wird in dem Treiber meines Front-Ends verwendet: drivers/media/dvb-frontends/si2168.c . Nur in einer Funktion die ganz nah zu der Hardware arbeitet - die sendet Kommandos dem Front-End Chip über I2C. Entschuldigung für Pseudocode und Englisch:

    Code
    si2168_cmd_execute() {
// -EREMOTEIO gets returned on three different occasions:
  A) i2c_master_send(cmd->wlen) != cmd->wlen  // cmd write error
  B) i2c_master_recv(cmd->rlen) != cmd->rlen  // response read error
  C) ((cmd->args[0] >> 6) & 0x01) > 0    // front-end silicon indicates error
}

    Ich habe in diesem Treiber folgende Änderungen gemacht - nicht in der si2168_cmd_execute() , eher in deren rufenden si2168_read_status(). Dreie extra "debug-Meldungen", wo das Problem auftaucht. Den Patch habe ich als eine Datei unter diese Nachricht eingeschlossen. Und in dem dmesg-Log habe ich jetzt:

    si2168_read_status(): failed to set the delivery system

    Also wir wissen schon, auf welcher Stufe es passiert. Vielleicht der Front-End Chip selbst meldet den Fehler?

    Und noch eine Sache wundert mich: in dem User-Space t2scan auftaucht das Problem nur in dem scan.c auf Zeile 2850.

    Ich habe bemerkt, daß das ioctl(FE_READ_STATUS) auch später verwendet wird: durch funktion check_frontend()auf Zeilen 2360 und 2383 = innerhalb der "scan-Schleife". Und, da wirft es keine Fehler! Komisch. Ich habe keinen Grund gefunden. Nirgendwas, was bei dem ersten Rufen auf Zeile 2850 unterschiedlich wäre. Z.b. das "front-end device" ist da schon geöffnet (anders würde das ioctl gar nicht erfolgen mit dem Treiber zu sprechen.)

    Ich möchte darüber spezifisch die Treiber-Maintainer in linux-media fragen... Haben Sie dazu manchen weiteren Kommentar? Sollte ich z.B. die dev_dbg() Meldungen in dem Treiber entkorken, und einen Log aufnehmen? Oder lassen wir das sein? :)

    :) Ich habe den Patch in dem Treiber vergessen, und der Fehler zeigt sich in dem Kernel (dmesg) auch wann ich VDR normalweise verwende - nur VDR klagt sich nicht. Ich sollte es wahrscheinlich auf linux-media als ein Bug melden?

    Hallo ,

    ab Juli soll in Italien auf DVB-T2 umgestellt werden. Daher habe ich mich ein bisschen informiert. Man möchte ja vorbereitet sein und nicht auf einige Sender verzichten müssen. Auf der Seite der lokalen Rundfunkanstalt RAS habe ich dann entdeckt, dass ein Testkanal ausgestrahlt wird :wow

    w_scan findet den Sender nicht. dvbv5-scan spuckt die ersehnten Zeilen aus, allerdings will vdr damit nicht: frontend x/0 timed out while tuning to channel. Heute habe ich dann diesen Thread entdeckt und mit der Option -p 1 erfolgreich den Kanal gescannt. vdr tuned damit korrekt und via streamdev bekomme ich in vlc Bild und Ton.

    mighty-p Danke für das hilfreiche Tool. Falls Du die Liste der getesteten Hardware auf gitHub erweitern möchtest, die Hauppauge WinTV-quadHD funktioniert damit. Eventuell wäre es nützlich den Parameter -p 1 für Italien standardmäßig zu setzen.

    VDR-Clients:
    Raspbian Buster     - vdr 2.4.1 - Raspberry PI 2B

    Home-Server:
    Debian Bookworm - vdr 2.6.0 (eTobi) - Kernel 6.1

    Asus Prime B360M-C - Pentium Gold G5400 - Mystique SaTiX-S2 Dual - Hauppauge WinTV-QuadHD

    motze Vielen Dank, vor allem auch zur Info bzgl. PLP ID für Italien. Ich werde mir das in den nächsten Tagen dann für Italien als Default einbauen, auch auf die Gefahr dass es für den Testkanal passt und im Regelbetrieb nachher nicht. Generell ist das, dass man die PLP ID wissen muss und t2scan nicht automatisch die richtige finden kann etwas, womit ich noch nicht zufrieden bin. Leider hab ich dafür bis jetzt halt keine bessere Lösung gefunden. Falls da jemand ne Idee hat, sind Vorschläge gerne willkommen :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login