[VDR4Arch] Kein digitaldevices-dvb-driver mehr (Paket enthält nix)

  • Hallo Leute,


    Da mein VDR 24/7 durchläuft und neben TV-Aufnahmen auch noch andere Services drauf laufen, mache ich relativ selten Kernel-Updates. Daher bin ich vielleicht oft etwas spät dran ...


    Jedenfalls war's gestern mal wieder soweit. Komplettes System-Update gemacht, ein Kernel war auch dabei (3.18.4-1-ARCH).
    Seither habe ich keinen Empfang mehr auf dem VDR. Ursachenforschung hat ergeben: Das Modul für meine DVB-Karte von Digital Devices ist nicht geladen. Eine Suche mit find hat auch ergeben, dass das Modul nicht mal auf der Paltte liegt.
    Dann mit

    Code
    1. pacman -S digitaldevices-dvb-drivers


    das Paket neu installiert. Modul leider immer noch nicht da. Also das Paket überprüft. Ist scheinbar (bis auf ein paar Metadaten) leer:

    Code
    1. root@vdr:~# tar tJf /var/cache/pacman/pkg/digitaldevices-dvb-drivers-3.18.2-1-any.pkg.tar.xz
    2. .PKGINFO
    3. .MTREE
    4. root@vdr:~#


    Kann da beim Paket-Bau ein Unfall passiert sein ?


    Wäre nett, das möglichst schnell zu beheben. Mir ist auch noch aufgefallen, dass das Paket eine leicht von der Kernel-Version abweichende Versionsnummer hat. Ob das was ausmach, bin ich aber nicht sicher.


    Ach ja ... ist bei mir ein 64 bit System. Vielleicht tritt das Problem ja nur da auf.


    Vielen Dank und beste Grüße,
    ratman

  • Kann da beim Paket-Bau ein Unfall passiert sein ?

    Nein, das ist wohl Absicht: https://github.com/VDR4Arch/vd…d4d5feb02a3da97d3290f0439

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Bedeutet das, dass die Driver jetzt offiziell im Linux-Kernel sind und die Distros das halt in der Kernel config aktivieren müssen ?


    In dem Fall würde ich mich natürlich an Arch Linux wenden ... nur was mache ich in der Zwischenzeit ?
    Das kann ja dauern, bis die das gemacht haben :-(

  • Mit Upstream ist Arch Linux gemeint, sondern dass man selbst das Vergnügen hat, daran zu arbeiten, dass die Treiber in den Kernel gelangen...

    nur was mache ich in der Zwischenzeit ?

    Treibermodule selber bauen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das dvbsky Paket ist rausgefolgen, weil einige Geräte ja schon ab 3.18 unterstützt werden und der Großteil dann mit 3.19. Die anderen Treiberpakete sind wohl rausgefolgen, weil Copperhead sie zumindest in der Form nicht mehr maintainen will?

  • Das ist Absicht. Wie in den "Metadaten" beschrieben ist es ein Dummypackage, das aus paketiertechnischen Gründen notwendig wurde. Ich habe es in einem Rutsch mit den DVBSky Treibern entfernt, die in Rekordzeit im Kernel angekommen sind.


    Klar könnte man jetzt ein DKMS Paket benutzen. Ich habe mich allerdings gegen ein DKMS Paket entschieden.


    Das liegt zum einen daran, dass ich damit immer noch Arbeit habe. Ich kann nicht einfach das dddvb-Paket nehmen und kompilieren. Es ersetzt nämlich inkompatibel ein grundlegendes Kernel-Modul (dvb-core). Um es kompatibel zu halten muss einiges in dddvb zurückgebaut werden.
    Das nimmt auch immer mehr Zeit in Anspruch, weil sich Digital Devices immer weiter von dem entfernt, was vom Kernelteam abgesegnet ist.


    Der zweite Grund, warum ein DKMS Paket nicht in Frage kommt wurde auch schon im Arch Linux Team besprochen. Arch Linux hat keine saubere Implementierung von DKMS. Wenn ich mich richtig erinnere wurde sogar schon darüber nachgedacht, das dkms-Basispaket aus Arch Linux zu entfernen.



    - Ich wollte dieses Problem selber angehen und habe auch eine kleine Änderung bis in den Kernel gebracht. Anstatt das diejenigen, die Ahnung davon haben einem helfend unter die Arme greifen, warten sie ab, bis sich mit der Änderung ein trivialer Fehler auftaucht und werfen einem dann vor, wie schlecht man das doch gemacht hat.


    - Digital Devices unterstützt Linux offiziell gar nicht mehr: Neubau VDR - Basis ASRock Q1900M und yaVDR


    - Seitens Digital Devices wurde mir zugesichert, dass bis Ende letzten Jahres erste Änderungen für die neuen Karten in den Kernel übertragen werden. Bisher ist nichts passiert.
    Mir wurde dabei ein im DVB-Umfeld sehr bekannter Kernelentwickler genannt, dessen Commits ich seitdem verstärkt beobachte.


    - Ich weiß von einem zweiten Kernelentwickler, der Ende Sommer 2014 mit den DD Treibern aufgegeben hat.


    - Man bekommt dann eingeredet, dass Treiber nicht in den Kernel gehören. (Sundtek ist da Meister). Treiber gehören unter Linux schon immer in den Kernel. Das war schon immer so und wird auch so bleiben.




    Alles in allem ist es meine Zeit. Die bekomme ich nicht wieder, für die bekomme ich kein Geld und die möchte ich nicht einer Firma wie Digital Devices schenken.


    Ich habe oben bewusst keine Namen genannt, die betroffenen Personen wissen Bescheid. Ich gehe aber jetzt schon davon aus, dass ich innerhalb von 24 Stunden eine PN oder E-Mail von Digital Devices erhalte, worin man mich von Digital Devices überzeugen möchte und mir eventuell wieder einen neuen Namen eines Kernelentwicklers nennt, der angeblich jetzt daran arbeitet.
    Das wäre nicht das erste mal. Das letzte mal habe ich meine Posts noch nachträglich abgeschwächt.


    Ich empfehle in Zukunft unter Vorbehalt (da ich selbst noch eine Cine S2 verwende und somit keine eigene Erfahrung habe) Karten von anderen Herstellern, die Treiber im Kernel haben. Ich bestreite nicht, dass die DD-Hardware gut ist. Die Treibersituation ist aber eine Zumutung.



    Jetzt könnt ihr mich gerne Beschimpfen oder mir Beipflichten, meinen Post kindisch nenne, oder meine ganzes Verhalten. Mir ist es egal.


    Achja eins noch. Ich habe von Digital Devices ein Octopus Net V1 S2/2 erhalten. Ein Vorserienmodell, wie man mir sagte (Defekter Powerschalter, teilweise defekte LAN-Ports). Zum einen komme ich mir seitdem irgendwie gekauft vor und zum anderen hat es nach vielen Versuchen noch nicht einmal richtig funktioniert. Wenn wir schon so bei klärenden Worten sind, könnte mir ja mal einer sagen, was ich damit jetzt am besten anstelle.



    Gruß
    Christopher

  • - Ich wollte dieses Problem selber angehen und habe auch eine kleine Änderung bis in den Kernel gebracht. Anstatt das diejenigen, die Ahnung davon haben einem helfend unter die Arme greifen, warten sie ab, bis sich mit der Änderung ein trivialer Fehler auftaucht und werfen einem dann vor, wie schlecht man das doch gemacht hat.

    Also, sowas ist natürlich richtig traurig. Von wegen Community ... :-(


    Meine Frage, was ich in der Zwischenzeit mache, war auch nicht als Vorwurf an Dich gemeint. Und nach Deinen Erläuterungen ist meine Befürchtung "Das kann dauern" ja noch mehr als bestätigt.


    Zu dumm, dass ich damals nach der erfolgreichen Inbetriebnahme der DD Hardware meine vorherigen DVB-Karten (Terratec) in der Bucht verkauft habe :-(
    Für neue Hardware ist gerade auch kein Budget da. Am Jahresanfang kommen bei mir immer einige jährlich zu zahlende Posten.

  • [...] - Ich wollte dieses Problem selber angehen und habe auch eine kleine Änderung bis in den Kernel gebracht. Anstatt das diejenigen, die Ahnung davon haben einem helfend unter die Arme greifen, warten sie ab, bis sich mit der Änderung ein trivialer Fehler auftaucht und werfen einem dann vor, wie schlecht man das doch gemacht hat. ....


    Tja, so ist nun mal das Leben. Man sollte halt die Finger von Dingen lassen, von denen man keine Ahnung hat. ;)


    Fehler machen Alle, nur sind die Meiste aber auch bereit, gemachte Fehler einzusehen und vor allem auch zu korrigieren!
    Einfach alles auf sich beruhen zu lassen und beleidigte Leberwurst zu spielen, ist sicherlich nicht die richtige Gangart...

  • Du kannst das dddvb-Paket laden und einfach make, make install machen. Da werden die Kernelmodule zwar etwas unschön in ein Verzeichnis geschweint, wo sie nicht hingehören, das ist aber spätestens beim nächsten Kernelupdate wieder rückgängig gemacht.
    Das funktioniert auch, solange du ausschließlich Karten von Digital Devices verwendest. Wolltest du da eine z.B. Terratec mit dazustecken, würde der Treiber der Terratec nicht laden.


    Nur mal so aus Interesse. Welche DVB-Karte benutzt du denn genau?


    Nochmal zu DKMS. Die Diskussion kam auch schon im Arch Team auf. Man wollte das nvidia Modul nicht ständig neukompilieren. (Das fällt ja glücklicherweise bald auch weg, da der Closed Source Treiber dann auch das nouveau Modul verwendet).
    DKMS läuft unter Arch Linux nur beim Systemstart und sollte eigentlich direkt nach der Installation des dkms-Pakets laufen. Man kam dann zu dem Schluss, dass DKMS nicht der richtige Weg ist.

  • Ich finde mit Leberwurst hat das nix zu tun. Copperhead steckt viel Zeit in vdr4arch. Er hält ja nicht nur die PKGBUILDs in Schuss, sondern stellt auch noch Binärpakete zur Verfügung, die er auf eigener HW baut. Ich finde wer macht, hat recht. Wer die Treiber braucht, baut sie sich dann halt selbst aus dem von DD bereitgestellten tree, auf die Gefahr hin das Mischbestücken nicht funktioniert bzw. nicht die neuesten Treiber vom Kernel geladen werden. Und media-build-experimental gibt es ja auch noch!


  • Zu dumm, dass ich damals nach der erfolgreichen Inbetriebnahme der DD Hardware meine vorherigen DVB-Karten (Terratec) in der Bucht verkauft habe :-(

    Wie gesagt es ist kein großes Problem sich die Treiber von DD oder das media-build-experimental, das UFO pflegt, selbst zu bauen - das ist nur ein bisschen Arbeit, weil man das einmal für jede neue Kernelversion machen muss. Beim media-build-experimental nutzt man dann natürlich idealerweise das jeweilige extramodules-Verzeichnis für den gewünschten Kernel.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • OK, dann muss ich wohl den gcc usw. auch noch auf dem VDR installieren.


    Ich habe eine Octopus Bridge und (bislang nur) eine DuoFlex-CT. Hier in BaWü gibt's ja keine Grundverschlüsselung.
    Andere DVB-Hardware habe ich nicht (mehr).

  • Ich könnte ja ein PKGBUILD bereitstellen. Kompilieren werde ich es aber nicht. Es vereinfacht es aber denjenigen, die auf die Treiber angewiesen sind.
    Das kommt aber auch erst, wenn ich mit den Prüfungen durch bin.


    (Schlimm. Noch nicht mal eine Stunde und ich knicke schon wieder ein)

  • OK, Prüfungen haben natürlich Vorrang.


    Ich werde mal probieren, ob ich mein System-Backup von vor 6 Monaten doch noch eingespielt bekomme. Die USB-Platte wo das drauf ist hat leider auch einen Schaden. Aber mit mehreren Versuchen und Geduld krieg ich das vielleicht zusammen.
    Ich probiere natürlich erst mal, das gesmate Backup-Verzeichnis (wurde mit storeBackup erstellt) woandershin zu rsync-en und sipele es nur ein, wenn ich das komplett schaffe.

  • OK, hat (fast) auf Anhieb geklappt. Ich musste nur noch das Paket perl-proc-processtable installieren, damit er es bauen konnte. Könnte man vielleicht noch in die dependencies eintragen.


    Der Riesen-Vorteil beim PKGBUILD war in dem Fall für mich, dass ich das Paket auf dem "großen" PC bauen und dann auf dem VDR installieren konnte.
    Der VDR-PC ist halt etwas minimal ausgestattet, hat auch kaum noch Platz auf der / Partition, sodass es mich schon Überwindung gekostet hätte, da auch noch gcc, make, usw... zu installieren.
    Auf dem "großen" PC dagegen ist das alles kein Problem und gcc eh schon drauf, weil ich da viele AUR-Pakete installiert habe.


    Also vielen Dank nochmal !


    Ach ja ... Ich habe gesehen, dass in dem PKGBUILD die Kernel-Version eingetragen ist. Ändert sich da in Zukunft noch mehr ? Und wo kriege ich dann immer wieder die aktuelle Version her ?


  • Ach ja ... Ich habe gesehen, dass in dem PKGBUILD die Kernel-Version eingetragen ist. Ändert sich da in Zukunft noch mehr ? Und wo kriege ich dann immer wieder die aktuelle Version her ?


    Das ist gerade das Problem an den "nicht im Kernel-Treibern". Mit jedem Kernel-Update musst du wieder ran. Deshalb steht da auch die Kernel-Version drin, damit du einen Konflikt bekommst sobald du ein Kernel-Update durchführen willst. In dem Fall musst du die Version im PKGBUILD entsprechend tauschen und nochmal kompilieren. Bisher wurde dieser Schritt, der bei Arch ja durchaus öfter mal nötig ist, auf Copperhead abgewälzt.


    Da du "großer PC" erwähnst: Es kann sinnvoll sein in der /etc/makepkg.conf noch die Anzahl der gleichzeitig laufenden Prozesse an die Anzahl der CPUs anzupassen. Dann läuft das noch schneller.

  • - Digital Devices unterstützt Linux offiziell gar nicht mehr: Neubau VDR - Basis ASRock Q1900M und yaVDR


    Ich weiß jetzt nicht wie der daraufkommt zu schreiben DigitalDevices unterstützt Linux offiziell gar nicht mehr. Leider muss ich schreiben: Dies ist ein dummer Kommentar, denn Lesen hilft !


    Die Linux4Media kann den telefonischen Support derzeit nicht mehr leisten, dies liegt eben auch an so netten Zeitgenossen wie Christopher/Copperhead. Das hat nichts mit der DigitalDevices zu tun !


    Wenn jemand fragt bekommt er Antwort, und Hilfe ! Nur überall die Produkte schlecht machen, und dann zu schreiben man käme sich gekauft vor, das hat einen Beigeschmack, sehr faden Beigeschmack !


    Schade, sehr schade. So funktioniert die Community nicht, aber das wissen viele die schon seit Jahrzehnten dabei sind.