Posts by kfb77

    Hi Stefan,
    mein VDR ist ein reiner Backend, somit hatte ich bis jetzt die Fernbedienung noch nicht getestet. Inzwischen habe ich das nachgeholt, konnte aber dein Problem nicht nachvollziehen.


    Mein System: Ubuntu 14.04, Kernel 3.13.0-43, VDR aus yavdr testing repository, DVBSky S952 (keine V3), Firmware manuell installiert, Treiber mediabuild von DVBSky via DKMS wie hier beschrieben, lirc installiert und mit "None" konfiguriert, inputlirc installiert und mit folgender /etc/default/inputlirc konfiguriert:


    Code
    1. # Options to be passed to inputlirc.
    2. # EVENTS="/dev/input/event*"
    3. EVENTS="/dev/input/by-path/pci-0000:04:00.0-event-ir"
    4. OPTIONS="-g -m 0"


    Damit konnte ich im VDR die mitgelieferte Fernbedienung anlernen. Es bleibt aber natürlich noch die Frage, ob das überhaupt Sinn macht, da dieser Fernbedienung einige wichtige Tasten fehlen, um einen VDR vernünftig bedienen zu können.

    Hi Stefan,


    nein, das habe ich nicht. Ich bin auch nicht wirklich erfahren im Erstellen von Paketen. Ich nehme aber mal an, du kannst das ? Es müsste eigentlich reichen von einem Rechner, auf dem es läuft, das Verzeichnis /usr/src/dvbsky_v4l-14.6.19 und die Firmware aus dem DVBSky media_build in das Paket zu übernehmen und dann die 3 dkms Befehle aus dem Script auszuführen. Der Rest vom Script baut nur die dkms.conf, die ist aber eh statisch.

    dkms remove die Meldung bzgl. -36 irritiert: "Status: Before uninstall, this module version was ACTIVE on this kernel."

    Das passt schon, dass bedeutet nur, dass das dkms Packet für den Kernel 36 installiert wurde und aktiv ist, wenn der Kernel gebootet wird.
    Ich vermute, deine Änderungen werden beim nächsten Kernel Update nicht ohne manuellen Eingriff wieder laufen.


    Die Prüfung "... is not newer than what is already found in kernel 3.13.0-39-generic (0.0.1)" sollte eigentlich durch den Eintrag "CHECK_MODULE_VERSION=n" in der dkms.conf verhindert werden. Die Versionsnummern der Module werden leider nur sporadisch hochgezählt, nicht bei jedem Update.


    Ich habe mal einen neuen Server unter 14.04 in einer VM aufgesetzt. Darin meine Scrips original aus dem Forum und genau deine Befehle ausgeführt. Deine Fehlermeldungen habe ich aber nicht bekommen. Als Anhang meine Ausgabe von make_dmks.sh. Vielleicht ist irgendwas mit deinem 39er Kernel durch die alten Versuche verbogen. Ich bin gespannt, was bei dir beim nächsten Kernel Update passiert.


    Vielen Dank für Dein DKMS und vor allem Deine umfangreiche Unterstützung zu jeder Zeit!
    (Inkl. Geduld mit den langen Kompilierzeiten meiner N54L - diese Maschine wird nachher zwecks VDR-Lasttest damit bestraft, parallel Priest und Glimmer Man aufnehmen zu müssen

    Gerne, Dank zurück für deinen Test. Auf meinem i3 geht das Kompilieren wesentlich schneller. ;-)

    So langsam gehen mir die Ideen aus.Genau so, wie du es gemacht hast, habe ich es auch gemacht. Bei mir sind danach alle *.ko unter /lib/modules/3.13.0-39-generic/updates/dkms, keine weitere Struktur. Diesmal hattest du aber den 39er Kernel gebootet, oder ? Mein Skript baut nur für den gebooteten Kernel.

    nein, das sieht gut aus, "--all" löscht alles, was von dkms installiert wurde von allen vorhanden Kernel Versionen. Jetzt hast du wieder den Stand von vor dem Test.


    Vielleicht wäre es jetzt ganz gut, nochmals nach Herstelleranleitung zu installieren (rm vom Kernel media Verzeichnis nicht vergessen, wegen der doppelten Modules ins verschiedenen Pfaden) und es erst danach nochmals mit dkms zu versuchen. Nur um sicherzustellen, dass bei dir nicht noch was Altes irgendwo rum liegt.

    oder sollte man noch irgendwo Symlinks abräumen müssen?

    Nein, braucht du nicht, das Script legt ja eh wieder den gleiche Link an. /lib/modules/$(uname -r)/updates/ müsste jetzt leer sein (eventuell außer einem leeren dkms Verzeichnis).

    Ich gehe mal davon aus, du hast den aktuellen von der DVBSky Seite (140619). Das kann gut sein, dass sich da noch was mit ursprünglichen sudo make KDIR26=... nicht verträgt. Ist unter /lib/modules/$(uname -r)/updates/kernel/drivers/media überhaupt was drin ? Eigentlich müsste man das gefahrlos löschen können. Ich würde aber bei solchen Aktionen vorher immer ein Backup der Systemplatte mit Clonzilla machen. Man weiß nie, was schief alles schief gehen kann ...

    Mache sicherheitshalber noch einen sudo dkms remove "dvbsky_v4l/14.6.19" --all, dann ist wirklich alles wieder weg. Welchen mediabuild tree nimmst du ?

    Falls du den -39er Kernel schon installiert hast, musst du nach dem booten sudo dkms install "dvbsky_v4l/14.6.19" ausführen und nochmals booten. Automatisch geht es dann erst mit dem nächsten Update. LIRC habe ich nicht im Einsatz, ist bei mir ein reiner Server ohne Frontend.

    Hallo TEN,


    das passt nicht, die dkms Befehle sollten ausgeführt werden und nicht in die dkms.conf. Muss wohl auch ein Problem mit den Codeblöcken sein. Ich habe die Datei oben eingefügt, versuche es mal mit der.

    Hallo TEN,


    die Firmware ist nicht mit dabei, die muss man einmalig nach der DVBSky Anleitung installieren. Die ändert sich ja auch durch den Kernelupdate nicht. Es sowieso einfacher ggf. Fehler zu finden, wenn man zuerst mal nach Hersteller Anleitung installiert und dann testet, ob damit alles geht. Dann ist die Firmware auch gleich mit drauf.


    Die cx23885.ko vom Original Kernel stört nicht, da zuerst im ../updates/... Verzeichnis nach den Modulen gesucht (und gefunden) wird.
    Die Patches aus den Code Blöcken gehen wirklich nicht, da sind Leerzeilen verschwunden. Ich habe sie durch angehängte Dateien ersetzt, die müssten jetzt funktionieren.

    Letzteres hatte ich im seit wenigen Wochen ausgelieferten Kernel versucht, musste dazu aber media_build-bst-13 neu aus dem Tarball erstellen, sonst wurde auch nach Boot in den aktuellen Kernel -39 von sudo make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install
    weiter nur nach /lib/modules/3.13.0-36-generic installiert.


    Ohne den make Output zu kennen, kann ich nur raten: Ich vermute, du hattest den ersten make unter 3.13.0.36 gemacht. Das merkt sich der mediabuild tree unter v4l/.version und ignoriert deinen Parameter. Um das los zu werden, brauchst du einen make distclean.


    Aber wir entfernen uns wieder von der eigentlichen Frage: Mein DKMS Vorschlag hat bei mir beim letzten Kernelupdate funktioniert. Die Treiber wurden für die neue Version automatisch beim apt-get dist-upgrade gebaut und richtig nach /lib/modules/3.13.0-39-generic/updates/dkms installiert. Nach dem reboot lief die S952 ohne manuellem Eingriff.

    Hallo TEN,


    ich habe die DVBSky S952 unter Ubuntu 14.04 mit Kernel 3.13 und media_build-bst-13-140619 im Einsatz. Ich bin gerade dabei zu versuchen, die Treiber in DKMS zu integrieren. Mangels Kernel Update seither ist es aber noch nicht getestet, also auf eigene Gefahr (manche würden vorher einen Image Backup vom System machen) !


    Anleitung:


    Voraussetzungen: Kernel ab 3.13., dkms aus yavdr main repository
    1. Makefile in media_build-bst-13 mit Makefile1.diff patchen (./v4l/build_x64.sh ggf. ändern, je nach dem für welches System gebaut werden soll)
    2. Makefile in media_build-bst-13/v4l mit Makefile2.diff patchen
    3. make_dkms.sh ins Verzeichnis media_build-bst-13 kopieren und mit sudo ausführen



    Dann booten und über das Ergebnis berichten.


    Edit 17.11.2014: Codeblöcke gegen Dateianhänge ausgetauscht


    Edit 21.12.2014: DKMS Hinweis hinzugefügt

    Files

    • Makefile1.diff

      (257 Byte, downloaded 156 times, last: )
    • Makefile2.diff

      (1.15 kB, downloaded 131 times, last: )
    • make_dkms.sh

      (692 Byte, downloaded 155 times, last: )

    Hallo Franzose,


    ich hatte das gleiche Problem. Ich habe es bei mir durch erweitern der /etc/init/vdr.conf gelöst. Damit startet der vdr erst, wenn der nfs mount durch ist:


    Code
    1. start on ((filesystem and started dbus and started udev and static-network-up and mounted MOUNTPOINT=<hier dein Mount Point>) \
    2. or (stopped vdr RESULT=failed EXIT_SIGNAL=?* \
    3. or stopped vdr RESULT=failed EXIT_STATUS!=[02]) \
    4. or resume)
    5. stop on runlevel [!2345]

    Ich habe mir inzwischen mal den starttls näher angeschaut, das Server Zertifikat ist wohl nicht gültig. Es ist ausgestellt auf eplists.homelinux.org. Damit wird mit den aktuellen perl Modulen unter Ubuntu 14.04 die Verbindung abgelehnt, weil der hostname nicht übereinstimmt.

    Ich konnte jetzt den Fehler nochmals weiter eingrenzen: Die Überprüfung des Serverzertifikats schlägt fehl. Da hat sich mit Ubuntu 14.04 wohl auch einiges an den zugehörigen perl Modulen geändert. Ich habe aber noch nicht rausfinden können, ob wirklich das Serverzertifikat nicht gültig ist (Verdacht: cn-Name <> hostname ?) und das vorher von perl nicht überprüft wurde, oder ob da noch was im Programm schief läuft. Hier mal nochmals ein Workaround, der nur die Zertifikatsprüfung abschaltet (nicht vergessen: my $UseSSL = 1 wieder eintragen, falls das geändert wurde).


    Das package hat aber noch ein Problem:


    /etc/cron.daly/vdr-addon-seriestimer lauft nicht.


    Fehlermeldung : "Unbekannte Zeile:"


    Ich konnte den Fehler eingrenzen auf ein Problem mit der perl ssl Schnittstelle.


    Als Workaround funktioniert bei mir:


    /usr/bin/svdrpsend-ng


    Option: my $UseSSL = 1 ändern auf my $UseSSL = 0


    Eine Lösung konnte ich aber nicht finden.


    Hat ihr das gleiche Problem ?


    Hat jemand eine Idee zur Lösung ?

    Hallo cactus-online,


    hast du yavdr testing auf Ubuntu 14.04 installiert ?


    In der Konstellation hatte ich das gleiche Problem. Da hat sich das Verhalten von perl ab 5.18 beim Abarbeiten von Listen mittels "key" verändert. Das ist jetzt zufällig.


    http://perldoc.perl.org/functions/keys.html


    Hash entries are returned in an apparently random order.


    http://perldoc.perl.org/perlse…ithmic-Complexity-Attacks




    Mein Workaround:


    /usr/share/perl5/Eplists.pm




    dieser Patch:


    --- Eplists.pm.dist 2014-04-25 11:16:25.315587041 +0200
    +++ Eplists.pm 2014-04-25 11:46:06.623551162 +0200
    @@ -1064,7 +1064,8 @@
    $OutputData{Data}[$i] = $Config{Format};
    }


    - foreach my $key ( keys %OutputData ) {
    + # foreach my $key ( keys %OutputData ) {
    + foreach my $key ( 'Prefix', 'Data' ) {
    for (my $i = 0; $i < scalar @{$OutputData{$key}}; $i++) {
    my %FormatM = ( "s" => 2, "e" => 2, "n" => 3 );
    foreach("s", "e", "n") {