[Gelöst]: Probleme mit FB beim restart/Reihenfolge der DVB Karten festlegen

  • HW-Config Nexus-S und Nova S Plus


    Kernel 2.6.15-ct-1 oder auch selbst gebackenem 2.6.16.20 nach Anleitung von wilderigel


    oder muss ich noch was anderes blacklisten?



    /etc/hotplug/blacklist
    dvb_ttpci
    cx2388x
    cx24123
    cx88_vp3054_i2c
    cx8800
    cx88_dvb
    cx88_blackbird
    dvb_core
    budget_core
    budget_ci

  • Aktualisierte Fassung (leider neues Posting, da man älter Postings nicht mehr ändern kann):
    11.07.06:
    -------------
    - Hinweis bzgl. sources.list eingefügt
    - core modules hinzugefügt


    13.07.06:
    -------------
    - Hinweis auf /etc/hotplug/blacklist für ctvdr 4.5



    Hier nochmal eine Zusammenfassung des Ganzen:
    Die Anleitung bezieht sich auf ctvdr5, sollte aber auch für 4 und 4.5 stimmen, nur dass dort eine ältere Version von hotplug zum Einsatz kommt, und daher das blacklisten laut http://www.vdr-wiki.de/wiki/in…der_DVB-Treiber_festlegen etwas anders geht (habs nicht ausprobiert).


    Das Problem:
    Problem 1:
    Bei Verwendung von TechnoTrend Karten (FullFeatuered und Budget zusammen in einem System, z.b. Nexus und Nova) kann es vorkommen dass die Treiber manchmal in der richtige Reihenfolge geladen werden (erst dvb_ttpci und dann budget_ci) und manchmal umgekehrt.


    Dies führt dazu dass z.b. das RemotePlugin (aber auch bei andere Funktionen, z.b. ältere Mplayer Versionen oder SmartCards an den TT Karten) manchmal funktionieren und manchmal nicht. Teilweise läßt sich dieses Problem durch umstecken der Karten in den PCI Slots entschärfen, aber die richtige Lösung findet sich hier.


    Problem 2:
    Zusätzlich zu diesem Problem gibt es aber noch ein zweites:
    Iin der /usr/sbin/runvdr ist ein Fehler der dazu führ dass bei einem VDR restart die DVB Treiber in genau der umgekehrten Reihenfolge geladen werden.
    D.h.: selbst wenn die FB normalerweise geht kann es bei einem VDR crash oder einen restart über das Menü dazu kommen dass die FB nicht mehr geht, weil die Treiber jetzt anders geladen werden.


    Die Lösung:


    Lösung zu Problem 2:
    (als erstes weil es alle betrifft)


    Das 2. Problem wurde in vdr_1.4.0-1ctvdr2_i386 gefixed, daher sollte man als allererstes sein System updaten:
    - /etc/apt/sources.online in sources.list umbenennen
    - weil sich das repository für die Multimedia Dateien geändert hat muss der nerim.net eintrag auf
    deb http://www.debian-multimedia.org sarge main
    geändert werden (z.b.: nano /etc/apt/sources.list)
    - apt-get update
    - apt-get upgrade


    Wer nicht updaten will kan auch manuell die datei /usr/sbin/runvdr editieren und die Funktion get_modulenames durch diese hier ersetzten:


    Code
    function get_modulenames()
    {
        if [ "$KVERS_2_6" ]; then
            MODULES=`lsmod | awk '/^dvb_core/ {gsub(/,/,"\n", $4); print $4}' | tac`
            [ "$MODULES" ] && MODULES="$MODULES dvb_core"
        else
            MODULES=`lsmod | grep dvb-core | cut -d'[' -f2 | cut -d']' -f1`
            [ "$MODULES" ] && MODULES="$MODULES dvb-core"
        fi
    }


    Bei manchen Systemen könnte auch vdrdevel zum einsatzkommen, dort muss dann statt der runvdr die runvdrdevel editiert werden


    Achtung: Wenn der VDR neu installiert wird und dabei eine version vor vdr_1.4.0-1ctvdr2 verwendet wird, wird diese Änderung überschrieben und muss daher von hand neu gemacht werden.


    Um zu prüfen welche Version installiert ist und welche Version installiert würde kann man
    - apt-get update
    - apt-cache policy vdr


    eingeben und erhält sowas:



    Wer nur das restart Problem hat ist hier fertig, aber es schadet meist nicht auch den Rest zu machen


    Lösung zu Problem 1:
    (nur für die bei denen die FB manchmal oder immer nach dem neu booten nicht geht)


    Man muss dafür sorgen dass die Treiber beim booten nicht (in falscher Reihenfolge) geladen werden.


    CTVDR5:
    Dafür trägt man in /etc/modprobe.d/blacklist einfach ganz unten folgendes ein


    blacklist dvb_core
    blacklist dvb_ttpci
    blacklist budget_core
    blacklist budget_ci


    CTVDR4 und 4.5:
    Hier befindet sich die blacklist an andere Stelle.
    Einfach in /etc/hotplug/blacklist.d eine datei erzeugen und die Module eintragen.
    - mit "touch myblacklist" die datei myblacklist erzeugen
    - mit einem editor folgendes eintragen


    Alternativ (ebenfalls ungetestet) soll es eine datei /etc/hotplug/blacklist geben in die das einzutragen ist


    dvb_core
    dvb_ttpci
    budget_core
    budget_ci


    Hab leider kein ctvdr4/4.5 system, wenns jemand getestet hat bitte hier posten, damit ich die Anleitung entprechend anpassen kann.



    Jetzt noch die treiber in /etc/modules eintragen damit sie in richtiger reihenfolge geladen werden


    dvb_core
    dvb_ttpci
    budget_core
    budget_ci


    (die core komponenten werden automatisch mitgeladen, aber Schaden auch nicht.-))


    neu booten und fertig


    Klingt komplizierter als es ist, kann man in weniger als 5 Minuten erledigen.


    Danke an alle die bei der Lösung geholfen haben !

  • Hallo Zielgruppe,


    was wäre noch notwendig um diese Lösung (Problem 1) auf eine PVR350 anzuwenden?

    easyVDR-1: DFi SD106, i3-7100T, PCIe Bifurcation: Asus NVIDIA GT 630 Rev. 2, & DD Octopus LE Bridge 2x DuoFlex v2, Noritake GU256x64D-3900B VFD , passiv gekühlt
    yaVDR2: Kontron KTQM67mITX, i7-3520M, 4GB DDR3, Asus NVIDIA GT 630 Rev. 2, Noritake GU256x64D-3900B VFD, SAT>IP
    easyVDR-2: bcm MX3150N, Pentium N3700, 4GB DDR3, ZOTAC GeForce GT 730 1x PCI-E, Sat>IP, Noritake GU256x64-372 VFD

    UP2VDR: UP Squared in Nexcom Nise 101 Gehäuse, Futaba VFD, passiv gekühlt
    SAT>iP: DD Octopus NET V2, Max A8, in Nexcom Nise 101 Gehäuse, semipassiv gekühlt

  • Nö, ich meine doch das Laden der Treiber.
    Ich habe ein Mischsystem FF DVB-C & PVR350! Die PVR drängelt sich beim Systemstart immer vor und ist somit video0. Somit habe ich z.B im Fernseher des VDR-Admin kein Bild ... Nur wenn die FF video0 ist hab ich dort ein Bild!?
    Oder bringe ich da was ducheinander?


    Gruß
    test.it

    easyVDR-1: DFi SD106, i3-7100T, PCIe Bifurcation: Asus NVIDIA GT 630 Rev. 2, & DD Octopus LE Bridge 2x DuoFlex v2, Noritake GU256x64D-3900B VFD , passiv gekühlt
    yaVDR2: Kontron KTQM67mITX, i7-3520M, 4GB DDR3, Asus NVIDIA GT 630 Rev. 2, Noritake GU256x64D-3900B VFD, SAT>IP
    easyVDR-2: bcm MX3150N, Pentium N3700, 4GB DDR3, ZOTAC GeForce GT 730 1x PCI-E, Sat>IP, Noritake GU256x64-372 VFD

    UP2VDR: UP Squared in Nexcom Nise 101 Gehäuse, Futaba VFD, passiv gekühlt
    SAT>iP: DD Octopus NET V2, Max A8, in Nexcom Nise 101 Gehäuse, semipassiv gekühlt

  • Hallo!


    Habe auch dieselben Karten (Nexus/Nova-S plus) und bei mir reicht es, zu den vier genannten (ttpci und budget Einträge) noch das Modul "cx88_dvb" zu blacklisten und in modules einzutragen. Dann stimmte die Reihenfolge bei mir.

  • Hallo


    bei mir klappt das mit dem einstellen der Ladereihenfolge leider nicht. Ich habe eine Nexus-S 2.3 und eine neue NOVA-T [cx88-treiber] (und nutzte inzwischen nur noch DVB-T).


    Ursprünglich war das mal nen 3er-CT. Aber der ist stets aktuell gehalten worden mit dem E-toby-Repositry. Kernel Version 2.6.16-ct-1 und vdr 1.4.1-1ctvd.


    Ich hab inzwischen alle 3 verschiedene Blacklist-einträge hinzugefügt, ohne Wirkung. Und auch das tauschen der Karten in den PCI-Slots hat nichts gebracht. Ich bin inzwischen ratlos.

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • Hochschieb.


    Das Problem ist immer noch aktuell. Beim booten wird immer noch jedes mal die Nova-T geladen (obwohl eigentlich alles geblacklistet ist). Ich hab inzwischen sogar den VDR deaktiviert und eigentlich sollten keine dvb-module mehr geladen werden. Dennoch wird die Nova-T immer noch geladen ?!?


    /etc/modules


    /etc/modprobe.d/blacklist


    /etc/hotplug/blacklist.d/dvb


    /etc/hotplug/blacklist

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • Ich hab in /etc/default/vdr das init-Script deaktiviert (eneabled=0). Der VDR startet ja auch dann nicht und die ttpci-module werden auch nicht geladen, aber die cx88-Module der Nova-T?!?

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • Ich wolle keinen neuen Thread aufmachen, da das ja thematisch 100% hier reinpasst.


    /avr/log/messages:

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    Einmal editiert, zuletzt von Negge ()

  • ok, da muss ich passen. Ich weiss nicht wo die CT Distri vielleicht noch
    einen superschlauen Lademechanismus an allen Standards vorbei,
    aufruft. Unabhaengig davon kannst du doch die Module auch nachtraeglich
    alle entladen z.B. mit


    Code
    modprobe -r budget-patch
    modprobe -r budget
    modprobe -r cx88_dvb


    Das sollte reichen um alle anderen Module ebenfalls zu entfernen. Wie
    sieht das Ergebnis von 'lsmod' dann aus?

  • Also das vdr stoppen, alle module alle entladen und in der richtigen Reihenfolge laden und anschließend vdr neu starten hatte ich schonmal probiert. Das funzt. Nur wie baue ich das in den Startprozeß (am besten vor das erste laden des VDR-Prozesses). Außerdem ist das eine meiner Meinung nach suboptimale Lösung, welche den startprozeß unnötig verlängert.

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    Einmal editiert, zuletzt von Negge ()

  • Ich hab gerade noch ein Fragment einer CT Distri hier gefunden.
    Bau es halt in '/usr/sbin/runvdr' ein (Funktionen unload_dvb_modules, load_dvb_modules).


    Die Blacklisterei ist meines Erachtens eh Unsinn, da, wenn der VDR wegen Treiberproblemen
    einen Reset machen moechte, eh alle Treiber erst entladen und anschliessend wieder
    geladen werden muessen (while Schleife ganz unten im Script). Und zwar zu beliebiger Zeit
    nach dem Reboot. Da ist es doch gerad egal ob die Treiber vor dem allerersten Start des VDR
    auch erst entladen werden muessen. Dauert keine Sekunde.

  • suboptimal ist richtig, so lange dauert es aber nicht. Besser, als es funktioniert gar nicht :D


    Am saubersten ist es, wenn du ein Script erzeugst das die Module entlädt, bevor vdr startet, dann ist auch bei einem Update keine Nachbesserung erforderlich.


    1. runlevel mit dem Befehl runlevel ermitteln, es wird N <level> ausgegeben, die Ziffer ist der runlevel. Im Normalfall sollte es 2 sein.


    Dann legst du das Script /etc/rc<Ziffer deines runlevel>.d/S19rmdvbmodules (z.B. /etc/rc2.d/S19rmdvbmodules) mit folgendem Inhalt an

    dann sollte es funktionieren.


    Oder du baust, es wie sparkie schrieb, in runvdr ein. Dann musst du aber nach einem Update, wenn die runvdr geändert wurde, die Änderung wieder einbauen.

    VDR1: AMD Duron-1300, 512mb RAM, Nexus-S rev2.1, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    VDR2: Athlon XP-M-2600+, 512mb RAM, TT Prem 1.3 DVB-S, Skystar2, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    Extern: Activy300, Gen2VDR V2

    Einmal editiert, zuletzt von geeg07 ()

  • @geek07


    Danke, das ist eine recht schöne Lösung. Die habe ich nun auch umgesetzt.
    Dabei sind mir aber verschiedene Probleme aufgefallen.


    1. Prinzpiell enläd er die Dateien und läd sie auch wieder neu. Dabei inkrementiert der VDR aber intressanterweise das IR-Devive. Also beim ersten boot ist die


    Nova-T:
    - frontent0
    - input cx88 IR as /class/input/input0
    Nova-S:
    - frontent0
    - input DVB on-card IR as /class/input/input1
    =>
    input: PC-Speaker as /Class/input/input2


    UNLOAD und LOAD der DVB-modules per script


    Nova-S:
    - frontent0
    - input DVB on-card IR as /class/input/input3
    Nova-T:
    - frontent0
    - input cx88 IR as /class/input/input4

    -----------------------
    2.Des weiteren läd der VDR nicht direkt nach dem Reboot. Der VDR stürzt beim ersten start ab. Mit der vielsagenden Fehlermeldung "runvdr: stopping after fatal fail ()" im Syslog. Auf dem TV erscheint dabei sehr kurz die Meldung (in Rot) "ERROR /dev/input/event0 PERMISSION DENIED". Dann ist der VDR abgeschmiert.
    Mit "/etc/init.d/vdr start" kann ich den VDR aber direkt danach problemlos starten und dann läuft er.

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    Einmal editiert, zuletzt von Negge ()

  • Das Problem mit dem /dev/input/event0 permission denied habe ich gelöst bekommen. Lag am "udev", wodurch die rechte bei jedem Reboot falsch waren. Nach deinstallation von udev geht es jetzt...

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • Zitat

    Original von Negge
    @geek07


    1. Prinzpiell enläd er die Dateien und läd sie auch wieder neu. Dabei inkrementiert der VDR aber intressanterweise das IR-Devive.


    Habe eine Nova SE2 und ne Nexus 2.3 (siehe [MT2] in Signatur)


    Diese Inkrementierung ist mir auch aufgefallen bei meiner CT5.


    Seltsamerweise erkennt die Kiste zudem bei der Nova ein IR-Interface obwohl sie keines besitzt X(


    Und die FB der neueren Nexus reagiert garnicht- auch nicht mit /evtest
    ist die keymap nicht eingebunden? Wundert mich eigentlich, dachte die Distri wäre recht aktuell...

    [MT1] Intel D945GCLF, 2GB DDR2, Nexus 2.1 Mod.564, Philips DVB-S Rev. 1.6 m. Grundig(?)-Chip, WD 800JB HDD 80 GB
    Software: c't VDR 6 (1.4.7-2ctvdr3, Kernel 2.6.18-6-486) Plugins: Remote

    [MT2] FS MT, Hauppauge WintTV Nexus-S Rev. 2.3 Mod. 564, Budget: Hauppauge Nova-SE2, Seagate Barr. 7200.7 160GB HDD
    Software: c't VDR 5 Plugins: Remote uvm

    Einmal editiert, zuletzt von radioking ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!