Beiträge von mighty-p

    Da mir keine wirklichen Probleme mit den letzten Git-Ständen berichtet wurden, habe ich nun t2scan 0.2 released (https://github.com/mighty-p/t2scan/releases). Vielen Dank an alle, die getestet und mir im Thread oder per Direktnachricht Rückmeldung gegeben haben!


    Ein Problem von t2scan derzeit ist, dass bei mehrfachem Empfang eines Programmes dieses dann auch doppelt (oder ggfs. noch öfters) in der ausgegebenen channels.conf steht. Der optionale Schalter "-d" kann zwar helfen, aber hier will ich in Zukunft etwas Besseres bauen und idealerweise das ioctl der DVB API nutzen, um das Programm nur vom am besten zu empfangenden Kanal zu nehmen. Entsprechende Änderungen werdet ihr bald im GIT sehen. Kann durchaus sein, dass v.a. der Schalter "-d" dann bei euch gar nicht geht oder instabil läuft. Das nur zur Info :)

    So, neue Änderungen wurden gerade ins GIT hochgeladen.


    Ich habe mal etwas bei den ganzen Optionen sortiert. DIe waren ja bis jetzt alle von w_scan übernommen. U.a. hab ich die ganzen Schalter für die Ausgabeformate durch einen einzigen "-o", der halt nen Parameter kriegt, ersetzt. Das finde ich einfacher. Dabei habe ich gerade auch das Default-Ausgabeformat von vdr 2.0 auf vdr 2.1.x geändert. Falls das keine gute Idee ist, sagt Bescheid, dann mach ich's rückgängig. An der eigentlichen Scan-Logik hat sich nichts geändert.


    "t2scan -h" zeigt jetzt wirklich nur noch die paar Optionen an, die für den normalen User Sinn machen. Alles andere ist in der Expertenhilfe "-H". Die man-Page ist auch entsprechend überarbeitet.


    Wenn es mit diesem Stand keine Probleme gibt, werde ich wohl am Sonntag oder Montag ein neues Release v0.2 erzeugen.


    jsffm - Danke für's Testen. Weitere Testberichte von anderen Usern sind gerne willkommen.

    :thumbup:


    Ich werde dann im GIT nachher die drei Dateien "proforma" hinzufügen. Bin eh gerade an t2scan am arbeiten. Bin die Optionen weiter am vereinfachen.


    Für die, die sich gerade an "-k" und "-K" (niedrigster, höchster Kanal zum Scannen) gewöhnen: Gewöhnt euch noch nicht zu viel dran, die beiden werden auf "-c"/"-C" (für "Channel") umbenannt :)


    P.S. jsffm Darf ich fragen, bei welcher Distri du benutzt?

    Hallo,


    basierend auf wirbel 's exzellentem w_scan habe ich ein neues Tool t2scan geschrieben, um DVB-T und DVB-T2 Kanäle zu scannen für die channels.conf.


    t2scan unterscheidet sich von w_scan wie folgt:

    • Anderer Ansatz beim Scannen: Im Gegensatz zu w_scan, das zwei Durchläufe über die einzelnen Kanäle macht, macht t2scan nur einen Durchlauf. Die NIT wird dabei nur benutzt, um die genauen Parameter des aktuellen Kanals zu ermitteln (d.h. Verweise auf andere Kanäle werden ignoriert) und von diesem werden die Services (Programme) direkt mit allen Daten eingelesen. Diese Design-Entscheidung habe ich gemacht, da ich festgestellt habe, dass (zumindest in meiner Region) die Verweise auf andere Kanäle in der NIT oft fehlerhaft waren und dazu geführt haben, dass entweder Kanäle nicht gefunden wurden oder durch falsche IDs der EPG nicht ging. Der Scan ist dadurch auch (zumindest bei mir) ein gutes Stück schneller. Der Ansatz von t2scan sollte eigentlich mit den meisten neuen DVB-T/T2-Karten funktionieren, da diese beim Tunen die meisten Parameter sowieso automatisch erkennen. Bei DVB-S würde der Ansatz nicht gut funktionieren, daher habe ich auch DVB-S (und -C) ganz aus dem Tool entfernt.
    • Nur noch DVB-T und DVB-T2. ATSC ist noch im Code drin, aber ungetestet. DVB-C und DVB-S/S2 werden nicht vom Tool unterstützt.
    • Neuer Parameter, um den DVB-T-Typ für den Scan festzulegen ("-t1" für nur DVB-T, "-t2" für nur DVB-T2). Dadurch geht der Scan natürlich schneller, wenn nur eine der beiden Arten gescannt werden soll.
    • Neuer Parameter, um den niedrigsten Kanal ("-c") und den höchsten Kanal ("-C") für den Scan festzulegen. Dadurch geht der Scan natürlich schneller, wenn man nicht den ganzen Bereich von Kanal 21 bis 69 scannen will (in vielen Regionen werden nur noch Kanäle unter 50 für DVB-T benutzt).
    • Weniger Optionen (und evtl. entferne ich noch weitere). Ziel ist es, das Tool simpel zu halten.

    Ich empfange recht viele DVB-T und -T2 Kanäle hier (alle vom französischen Sender Metz in DVB-T, alle vom luxemburgischen Sender Dudelange in DVB-T, alle DVB-T2 Kanäle im Saarland, und noch die DVB-T-Kanäle vom Sender Saarburg; manchmal klappt auch noch der Empfang des belgischen DVB-T-Senders Leglise). Diese werden mit dem Tool bei mir mit einer DVBSky T9580 v3 Karte problemlos und meines Erachtens auch korrekt eingelesen.


    Download:

    Wenn euch das Tool interessiert, findet ihr es hier: https://github.com/mighty-p/t2scan/ (entweder das Git-Repository clonen oder unter das ZIP unter https://github.com/mighty-p/t2scan/releases herunterladen).


    Mich würde interessieren, ob t2scan bei euch funktioniert und alle Kanäle wie erwartet findet. Bitte schreibt einfach hier im Thread oder öffnet (bei Problemen) ein Issue auf Github. Pull-Requests werde ich mir natürlich auch angucken. Bitte habt Verständnis, dass ich von der ganzen Materie aber bei weitem nicht so viel Ahnung wie wirbel habe. Ich dachte trotzdem, dass der Stand des Tools gut genug ist, um ihn mit der Community zu teilen :)

    Und da sich bei Beitrag mit dem von 447377 überschnitten hat: Klar, wenn du auf einfache Weise die libva updaten kannst, ist das natürlich ideal. Für Mint habe ich leider noch keinen "offiziellen" Weg gefunden, bei dem ich mir wirklich sicher bin, dass es sich nicht auf andere Software in der Distribution auswirkt und ich nicht die Update-Fähigkeit des Systems riskiere.

    kls schrieb:

    Gelten die Parameter von softhddevice nicht mehr für vaapidevice?

    Warum ist libva schon wieder zu alt? (openSUSE 42.2!)

    Welche Version von libva ist denn bei openSUSE 42.2 dabei? Was sagt das Kommando "vainfo"? Obwohl die Entwickler von vaapidevice ja eine libva >=2.0.0 empfehlen, funktionert es bei mir auf Mint 18.3 auch mit der veralteten libva 1.7.0, so lange ich im OSD die ColorBalance ausschalte (ansonsten hab ich Streifen im Bild).


    Die Parameter dürften sich eigentlich nicht groß geändert haben. Ich würde aber trotzdem mal probieren, das "-v va-api" wegzulassen (braucht man definitiv nicht) und beim "-a" mal etwas "einfacheres , etwa nur "-a hw:0,0", zu probieren.

    Hallo Ulrich,


    danke für die neue Version, gerade installiert und läuft :)


    Eine Frage habe ich aber. Vor geraumer Zeit (sicherlich mehrere Monate, wenn nicht sogar noch länger) wurden mir nicht nur auf den ARD-Sendern, sondern z. B. auch auf ROCKANTENNE Infos zum Programm angezeigt. Irgendwann ging das nicht mehr. Liegt das daran, dass keine Infos mehr gesendet werden, oder können aktuelle radio-Plugin-Versionnen das verwendete Format nicht?

    Die große Frage wird hier sein, ob du die S2-6400 als Ausgabegerät nutzen willst, oder auf eine Softwarelösung setzen willst. Bei letzterem stellt sich zurzeit dann noch die Frage, ob man weiter auf nvidia setzt (hat wohl gerade bei SD [das ja hochskaliert werden muss] die besten Qualität, aber vdpau ist auf einem "deprecation path" ist und wurde bereits aus aktuellen ffmpeg-Versionen entfernt und ein Plugin für die neue nvenc-Schnittstelle scheint es noch nicht zu geben). Alternativ kommt Intel mit vaapidevice-Plugin in Betracht (hier reichen die onboard-Grafiklösungen, die in aktuellen Intel CPUs integriert sind).

    Dr. Seltsam schrieb:

    Ich habe die letzten Jahre das nur am Rande verfolgt und bin nun etwas verwirrt. Ist VAAPI jetzt die stabilste Lösung? Was für eine Grafik brauch ich da? Werd ich da noch was mit der onboard-Grafik eines i5-4570?


    Also VAAPI auf Intel läuft bei mir absolut stabil (mit dem neuen vaapidevice-Plugin). Es wird immer gesagt, dass gerade bei SD die Qualität etwas schlechter sein soll als Nvidia mit VDPAU, aber ich kann nichts negatives sagen (habe aber auch keinen direkten Vergleich).

    Ob die i5-4570 reicht, weiß ich nicht. Ich hab mal gegoogled und die scheint ja schon etwas älter zu sein. Kommt darauf an, welche Formate in Hardware dekodiert werden können. Aber zumindest H.264 (HD über Sat) sollte eigentlich gehen, H.265 (HD über DVB-T2) ist kritischer. Was sagt denn "vainfo"?


    Eigentlich müsste doch auch nvidia mit vdpau auch noch gehen, wenn man die ffmpeg manuell in einer kleineren Version (z. B. 3.3.x) in /opt installiert und dann softhddevice gegen dieser Version linkt (also beim Kompilieren/Starten PKG_CONFIG_PATH bzw. LD_LIBRARY_PATH passend setzt). Könnte ne Notlösung sein, bis jemand eine Art "nvdecdevice-Plugin" schreibt.


    Und wo wir schon dabei sind, noch ne Frage: Auf meinem "VDR 1" benutze ich ja derzeit vdpau mit nem originalen softhddevice von Johns auf der ATI/AMD-Grafikkarte. Hat eigentlich schon jemand mal versucht, eine solche Konfiguration auf vaapi und vaapidevice umzustellen? Angeblich sollen die AMD-Karten ja mit vdpau und vaapi gleichermaßen funktionieren. Ich würde es sonst in den nächsten Wochen (vorher komme ich leider nicht an den VDR 1) mal versuchen.

    We're not going to downgrade the libva requirement, but we might even upgrade it to 2.1. There's no point using any media library from 2016.

    That's well understandable. On the other hand, popular distros (like Ubuntu or Mint) still come with pretty old libva versions. For me, it's simply less risky to patch one file (video.c) in vaapidevice than manually upgrading a system-wide library where I don't know which side effects on other software in the distro it will have. But as I say, I understand your point and for me it is no problem.

    Mir ist es gerade gelungen, das neue vaapidevice-Plugin (aktueller Stand von

    https://github.com/pesintta/vdr-plugin-vaapidevice/) zu Kompilieren und zum Laufen zu bringen.


    447377 die von dir beschriebenen Probleme hatte ich nicht. Das C99-Ding scheint inzwischen gefixt zu sein, vielleicht klappt es mit dem akutellen GIT-Stand ja jetzt!?


    Ein paar Anpassungen musste ich trotzdem in der Datei video.c machen, da in meinem System (Mint 18.3, entspricht in etwa Ubuntu Xenial, mit in /opt nachinstalliertem ffmpeg 3.3.2) eigentlich die libva zu alt ist. Das kann man aber mit ein paar Anpassungen umgehen (falls jemand sie braucht, kann ich nen Patch hier anhängen).


    Größtes Problem war, dass ich erst mal keinen Ton mehr hatte. Ich fand dann heraus, dass man wohl jetzt unbedingt den "-a" Parameter mit dem richtigen Device angeben muss, bei mir "-a pulse". Auf den ersten Blick scheint jetzt alles zu funktionieren.

    Hallo felix-s,


    auf der von dir verlinkten Seite steht doch eigentlich klar und deutlich, dass man für die aktuellen Kernel den Code von git.linuxtv.org benutzen soll. Die weiter unten verlinkten media_built_bst-Pakete scheinen mir auch bereits sehr alt zu sein (laut Dateinamen ist das alles von 2012 bis 2016).


    Na ja, egal. Ich vermute mal, dass die Original-Kernelmodule im System von den von dir selbst kompilierten überschrieben wurden. Ich würde daher versuchen, alle Kernelpakete aus deiner Distribution nochmal neu drüber zu installieren (oder gleich den Kernel auf ne neuere Version, falls vorhanden, hochzuziehen). Dann sollte es eigentlich wieder gehen.