w_scan_cpp

  • Noch ein Päckchen für den Weihnachtsbaum.

    Ob das hier die richtige Foren Kategorie ist, schwierige Frage, hat auf jeden Fall hat es mit Plugins zu tun..




    Wer ab && zu noch w_scan benutzt hat, für den gibt es jetzt den Nachfolger namens w_scan_cpp.


    w_scan_cpp ist ein DVB Kanalscanner und der Nachfolger von w_scan.

    w_scan_cpp besteht aus vier Komponenten:


    1. C++11 Quellcode (das Tool namens "w_scan_cpp")
    2. dem Programm VDR
    3. dem VDR wirbelscan Plugin als DVB Scanner
    4. dem dem VDR satip Plugin zur Unterstützung von SAT>IP

    Der Quellcode der zusätzlichen Komponenten (VDR, wirbelscan, satip-Plugin) ist nicht Teil dieses

    Source Paketes.

    Zum einfacheren Umstieg ist die Kommandozeilen Syntax weitgehend kompatibel zu der von w_scan.

    Wer schon einmal w_scan benutzt hat, wird wissen, wie dieses Tool zu benutzen ist.

    w_scan_cpp unterstützt

    • DVB-T(2), DVB-C, DVB-S(2), ATSC(VSB && QAM)
    • SAT>IP
    • SCR ("Unicable") EN-50494 und EN-50607 (aka. "JESS")
    • DiSEqC Switches
    • DiSEqC Rotoren (Standard und USALS)
    • verschiedene Ausgabe Formate
      • VDR channels.conf
      • VLC channels.xspf
      • dtv scan tables für dvbv5-scan
      • channels.dat für den SAT>IP "DVB Viewer Lite for Windows"
      • (..)

    Einige Features sind aktueller als die von w_scan, einige veraltete Features wurden nicht übernommen.



    Link zu w_scan_cpp

  • @1: ja


    @2: keine Abhängigkeit, beides ist prinzipiell separat.

    Aber die Möglichkeit, die jeweils letzte Version des Plugins sowohl für das eine als auch das andere zu nutzen, sofern vor dem build jeweils alle alten Objekt Dateien mit einem make clean sauber abgeräumt wurden. Das Plugin und die commandline Version nutzen andere Compiler Flags.

  • Schade, dass andere Nationen deutlich aktiver beim Feedback sind.

  • Hallo wirbel


    ich habe mir gestern w_scan_cpp heruntergeladen und installiert (unter Arch). Damit wollte ich eine Senderliste für VLC erzeugen. Eine Liste habe ich auch, nur sind dort einierseits nur sehr wenige Sender enthalten und andererseits stimmen die Parameter nicht, so dass VLC meckert. (Die Frequenzen der Sender werden falsch eingetragen. Einerseits werden KHz angegeben, obwohl Hz benötigt werden, andererseits werden die KHz irgendwie nur auf Tausender abgerundet eingetragen.) Nach manueller Korrektur funktioniert es aber so wie. Dies gilt für die Version vom Ende März.


    Falls es hierzu einen offiziellen Bugtracker gibt, kann ich die Infos auch dort gern eintragen.


    VG


    Smoerrebroed

  • Schick mir mal die erzeugte und die korrigierte Version an die email in der README.

  • Die nächste Version wird ähnlich femon Signal Infos ausgeben, wenn ich Zeit hab..


    z.B. SAT>IP


    oder lokale Frontends, hier DVB-C

  • Ein paar Beispiele zur Benutzung


    Astra 19.2

    Code
    1. w_scan_cpp -fs -sS19E2


    Astra 19.2 via SAT>IP

    Code
    1. w_scan_cpp -fs -sS19E2 --satip


    Kabel, DE, Adapter /dev/dvb/frontend0

    Code
    1. w_scan_cpp -fc -cDE -a0


    T/T2, DE

    Code
    1. w_scan_cpp -ft -cDE


    Kabel, DE, vorsortierte Liste (einige Services andere Namen als im Kabelnetz)

  • Ich habe das SatIP Plugin installiert aber beim Ausführen von w_scan_cpp wird mir kein Device angezeigt:


    Muss im SATIP Plugin in der /etc/vdr/conf.avail/satip.conf etwas konfiguriert werden oder funktioniert die Erkennung des Digitbit Twin automatisch ( wie bei den Android apps ) ?


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

  • 20210218 <- zu alt.


    Ansonsten hilft dir auch die commandline hilfe des tools weiter, den switch '--satip' zu finden.


    w_scan_cpp -fs -sS19E2 --satip

  • Nachdem in der /etc/vdr/conf.avail/satip.conf den Parameter -d 1 (, für ein SATIP Tuner, führendes Leerzeichen nicht vergessen sonst geht es nicht ) hinzugefügt habe funktioniert es auch mit der "zu alten" Version :



    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

  • Das Program liest keine VDR Konfigurationsdateien, interessiert sich nicht für die Installation deines VDR und du kannst keine Plugin Parameter übergeben, die du nicht in der Kommandozeile angibst.


    Der Unterschied ist das '--satip'.


    Nachtrag @"zu alte" Version:

    Einer der Verbesserungen in neuren Versionen war die Erkennung von satip Servern, die bei sporadisch in ein timeout gelaufen ist.

  • Ahhh der Groschen ist gefallen ;) THx 4 Info ;)


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

  • Falls jemand die aktuelle Version bauen will, muss dazu eine kleine lib namens librepfunc vorher installiert werden.

    https://github.com/wirbel-at-vdr-portal/librepfunc


    Einige Teile des wirbelscan Plugins und von w_scan_cpp waren doppelt mit fast gleicher Implementation - das macht die Pflege auf Dauer zu fehleranfällig.

  • Ist zwar nur meine unwesentliche Meinung, aber vielleicht wäre da ein "git submodule" besser gewesen. Dann hättest du die Sachen trotzdem an einer Stelle, man baut da aber nicht potentiell Querreferenzen auf. Also der Form "wenn librepfunc aktualisiert wird, dann muss w_scan_cpp und wirbelscan-plugin neu gebaut werden". Oder noch schlimmer: Neue w_scan_cpp braucht neuere librepfunc und zieht damit ein rebuild von wirbelscan-plugin nach sich.


    Muss aber jeder selber wissen wie er entwickeln will. Hätte nebenbei auch den Vorteil gehabt das mit jedem Commit im GIT die korrekte zugehörige Version (commit-ID) von "librepfunc" verlinkt ist.

  • git submodule ist schwierig, btw. hat seahawk1986 schon (richtigerweise) dazu schon den Hinweis gegeben..



    "wenn librepfunc aktualisiert wird, dann muss w_scan_cpp und wirbelscan-plugin neu gebaut werden"


    Warum denn?

    Wenn man API-kompatibel sollte jede API-kompatible lib passen: MAJOR gleich, MINOR >= required.



    Ich denke, ab einem gewissen Stand wird diese lib nur noch erweitert, aber bleibt immer abwärtskompatibel.

    Sprich: ich plane nicht, die Major Version anzufassen, wenn das irgendwie vermeidbar ist, siehe Kommentare im Makefile dazu.

    Minor (abwärtskompatible Erweiterung der API) und Patch (API untouched) dagegen schon.

    Wird (hoffentlich) immer eine 1.x.x bleiben.



    "Neue w_scan_cpp braucht neuere librepfunc und zieht damit ein rebuild von wirbelscan-plugin nach sich."

    Wenn w_scan_cpp eine neuere librepfunc braucht, wird in dessen Makefile dessen Version erhöht und per pkg-config --at-least geprüft.

    required 1.N.xx -> 1.(N+1).xx



    Das ändert wenig an den Anforderungen des Plugins, das sollte mit 1.N.xx oder 1.(N+M).xx glücklich sein, mit M >= 0.


    Wo ist dein Problem?

  • git submodule ist schwierig, btw. hat seahawk1986 schon (richtigerweise) dazu schon den Hinweis gegeben..

    Warum ist das schwierig und wo ist dieser Hinweis?


    Letztlich natürlich deine Sache wie du das machst.


    Derjenige, der aktuell das PKGBUILD für Arch pflegt denkt wohl drüber nach statisch zu linken. Ich warte mal ab und kopiere mir das dann ggf. für wirbelscan.

  • "Derjenige, der aktuell das PKGBUILD für Arch pflegt denkt wohl drüber nach statisch zu linken. Ich warte mal ab und kopiere mir das dann ggf. für wirbelscan."

    Oh je...


    Also wenn das dein einziges Problem ist, ich habe den Maintainer schon vor zwei Tagen kontaktiert.

    Es gibt ab sofort librepfunc-1.1.1 (Stand heute abend) in Arch, auch Dank seahawk1986. Danke an Alex btw.


    https://aur.archlinux.org/packages/librepfunc/
    https://aur.archlinux.org/cgit/aur.git/log/?h=w_scan_cpp


    Immer diese Aufregung um nix, nur weil man es wagt, gleiche Funktionen in vier verschiedenen tools (!) in eine vom Autor aller vier gemeinsam gepflegte und abwärtskompatible lib zu stecken, in der dann die Fehler für alle vier ausgemerzt werden und von denen alle profitieren.

  • Es gibt keine Aufregung. Das letzte über das ich mich noch aufregen werde ist VDR und alles drumrum. Was "low effort" möglich ist wird gemacht. Alles andere nicht mehr.


    Und "git submodule" war nur ein Vorschlag. Hätte mich einfach mal interessiert warum nicht dieser Weg gegangen wurde. Bei einem anderen Projekt (nicht VDR) nutze ich submodules zu meiner vollsten Zufriedenheit um gemeinsam genutzten Code global zu pflegen.


    Und das librepfunc PKGBUILD ist leider nicht ganz sauber gemacht. Ich hab für vdr4arch sowieso eigene PKGBUILDs und importiere nur das was "gut" ist vom AUR. In dem Fall wird es dann wohl ein eigenes PKGBUILD werden. Hab dem Autor aber auch geschrieben was er anpassen müsste.