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

  • Edit: die weiter unten beschrieben Lösung ist besser (änderung an runvdr und einträge in /etc/modprobe.d/blacklist und /etc/modules)


    Mit ctvdr5 hatte ich das im 1. Post beschrieben Problem wieder und nach langem basteln ist für meinen Fall (Nexus und Nova karte mit Remote Plugin) folgende Lösung bis jetzt die zuverlässigste:


    Ich habe sowohl in /etc/init.d/vdr wie auch in /usr/sbin/runvdr modprobe Einträge zum entladen und laden der treiber eingefügt und die ursprüngliche logik deaktiviert. Die angehängten scripts funtionieren so wie sie sind einwandfrei, allerdings eben nur mit den erwähnten Karten. Wenn andere Karten mit im System sind muss man die Einträge anpassen.

  • ja, nur das problem ist anscheinend der vdr restart, denn beim restart lädt ein script das ganze neu, und dabei klappt das manchmal nicht... ich werde mir den link nochmal anshen, aber ich weiss zumindest mit sicherheit dass meine jetzige lösung zuverlässig arbeitet...


    danke für den Link:-)

  • ich habs auf die von dir vorgeschlagene weise probiert und es funktioniert auch (fast), aber nach einem vdrrestart geht mal wieder die FB nicht.


    ich bleibe bei meiner Lösung, die ist zwar nicht elegant, aber zuverlässig.


    trotzdem danke !

  • Ich war auch genervt davon, dass nach jedem Restart des VDRs über runvdr meine Karten 1 und 2 vertauscht wurden. Der Grund dafür ist, dass im c't-VDR runvdr-Skript die Variable MODULES in der falschen Reihenfolge befüllt wird. Ich habe daher die Zeile

    Code
    1. MODULES=`lsmod | awk '/^dvb_core/ {gsub(/,/," ", $4); print $4;}'

    durch

    Code
    1. MODULES=`lsmod |awk '/^dvb_core/ {i=split($4, arr, /,/); for (;i>1;i--) printf "%s ",arr[i];print arr[1]}'`

    ersetzt, dann ging's! Die Module musste ich natürlich auch in /etc/modules eintragen, aber das hast Du ja schon.


    Bis demnächst,
    ARK

    VDR
    ASUS A7N8X-X, AMD 2600+, 2 GB, 320 GB HD, Hauppauge DVB-S 1.3, Hauppauge Nova-S-Plus, Funktastatur
    Debian 4.0/Etch-Kernel 2.6.18-5-486
    c't-VDR 6.1 mit e-tobi 1.6.0 (neu gepatched ohne sortrecordings), acpi, vdradmin-am, burn, osdteletext, ffnetdev, audiorecorder, infosatepg, ...
    Client
    dbox2 (Sagem 2xI_C) mit Neutrino-Derivat

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von ark ()

  • Moin,


    beim ctvdr 5 (hardware siehe signature) hat bei mir folgendes geholfen:
    /etc/modprobe.d/blacklist:

    Code
    1. blacklist dvb_core
    2. blacklist dvb_ttpci
    3. blacklist budget_ci
    4. blacklist budget_core


    Sowie eine Date /etc/modutils/addons.EMSKER mit folgendem Inhalt aufgebaut:

    Code
    1. dvb_core
    2. dvb_ttpci
    3. budget_ci
    4. budget_core


    und danach "update-modules" aufgerufen, dass hat dann "/etc/modules.conf" neu und richtig gebaut und schon ging es ohne irgendwelche Änderungen an vdr/runvdr


    Vewandte Themen:
    [list=1]
    [*] dvb-ttpci firmware wird manchmal gelanden manchmal nicht
    [*] c't VDR 5: nur 1 video device gefunden (wo ist die 2.Karte?)
    [/list=1]


    Danach musste ich dem nvram nur noch ein "--no-floppy" für den grub-reboot beibringen, und jetzt rockt der ctvdr5 richtig gut... und man merkt gegenüber dem 3.07 / VDR1.2 die Unterschiede...


    Fazit: Mit ein bischen Frickelei (modules, lirc-device, etc) klappts auch mit dem ctvdr5. Schade, dass heise die Kleinigkeiten nicht schon in der distri klar bekommen hat.


    Gruß + Danke an euch alle,
    emsker

  • Das Laden der Module hatte ich auch nicht gemeint. Es ist einfach so, dass im runvdr von c't VDR die Modul-Reihenfolge getauscht wird, so dass bei einem Restart innerhalb des Skriptes die Module erst entladen und dann in umgekehrter Reihenfolge wieder geladen werden. Da ist es schon irritierend, wenn Karte 1 und 2 auf einmal getauscht sind - vor allem wenn man Skripte hat, die auf der Kartennummer basieren. Daher meine Änderung, die die korrekte Reihenfolge der Module ermittelt.


    Bis demnächst,
    ARK

    VDR
    ASUS A7N8X-X, AMD 2600+, 2 GB, 320 GB HD, Hauppauge DVB-S 1.3, Hauppauge Nova-S-Plus, Funktastatur
    Debian 4.0/Etch-Kernel 2.6.18-5-486
    c't-VDR 6.1 mit e-tobi 1.6.0 (neu gepatched ohne sortrecordings), acpi, vdradmin-am, burn, osdteletext, ffnetdev, audiorecorder, infosatepg, ...
    Client
    dbox2 (Sagem 2xI_C) mit Neutrino-Derivat

  • ARK
    Auf meinem system lautet die zeile


    Code
    1. lsmod | grep ^dvb_core | awk '{print $4;}' | awk '{ gsub(/,/," ", $1); print }'


    und ergibt


    budget_ci budget_core dvb_ttpci stv0299


    deine ursprüngliche zeile ergibt bei mir aber das selbe ergebnis


    die geänderte version ergibt dagegen


    stv0299 dvb_ttpci budget_core budget_ci


    und somit die richtige reihenfolge.


    emsker


    deine Lösung ist schon OK, alledrings löst sie das restart problem (sie letztes posting von ark) nicht (ich habs getestet)


    Danke an alle, ich denke (hoffe) ich habe den bug im griff, es wäre aber doch gut wenn man das mal im paket ändern könnte.


    ARK : bist du evtl. bereit deine änderung mal an tobi, oder an die ct zu schicken, oder soll ich das machen (ich kann die Zeile leider nicht erklären:-()

  • Hallo ...
    Wie sich herausstellte, bin auch ich betroffen ...
    An einer dauerhaften Lösung "arbeite" ich gerade.
    Kann mir aber jmd. sagen, warum ich dieses Problem früher noch nicht hatte; also durch was/evtl. welche VDR-Version wird es hervorgerufen. Oder hatte ich viell. auch nur Glück, dass die FF mit FB sehr oft als erstes Device erkannt wurde ?



    Hat die CT eigentlich irgendwas zu der Problematik, man könnte es ja auch Fehler nennen, geantwortet ?
    Ich möchte wirklich nicht mutmassen, aber wie kann es sein, dass sich das unentdeckt (?!) schon über mehrere CTVDR Releases erstreckt ?




    Grüsse aus Aachen


    FA

    easyVDR 0.8.06


    Coolermaster ATC 620 SX1 / Asrock K7S41GX [2.80] / Geode NX 1750+ / 512 MB RAM / Samsung HD400LD / TT-FF 1.5 / AVBoard 1.4 / TT-Budget S1102 / LG-GSA 5163D

  • Ich war auch betroffen, in der Version 3.06 ging's noch, in der 4.5 waren meine Budget- und die FF-Karte vertauscht. Der Grund ist wohl die Umstellung des Ladens der Module auf hotplug gewesen. Na ja, habe ich halt die Module in die /etc/modules geschrieben, ich habe auch nur einen Abend gebraucht, bis ich es verstanden habe :rolleyes:
    Das Problem mit dem Tauschen der Module in der runvdr gab's wohl schon länger, unangenehm aufgefallen ist es mir erst mit der 4.5, meinen Fix dafür hat allow ja schon oben zitiert.


    Bis demnächst,
    ARK

    VDR
    ASUS A7N8X-X, AMD 2600+, 2 GB, 320 GB HD, Hauppauge DVB-S 1.3, Hauppauge Nova-S-Plus, Funktastatur
    Debian 4.0/Etch-Kernel 2.6.18-5-486
    c't-VDR 6.1 mit e-tobi 1.6.0 (neu gepatched ohne sortrecordings), acpi, vdradmin-am, burn, osdteletext, ffnetdev, audiorecorder, infosatepg, ...
    Client
    dbox2 (Sagem 2xI_C) mit Neutrino-Derivat

  • 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
    - 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
    1. function get_modulenames()
    2. {
    3. if [ "$KVERS_2_6" ]; then
    4. MODULES=`lsmod | awk '/^dvb_core/ {gsub(/,/,"\n", $4); print $4}' | tac`
    5. [ "$MODULES" ] && MODULES="$MODULES dvb_core"
    6. else
    7. MODULES=`lsmod | grep dvb-core | cut -d'[' -f2 | cut -d']' -f1`
    8. [ "$MODULES" ] && MODULES="$MODULES dvb-core"
    9. fi
    10. }


    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_ci
    blacklist budget_core


    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


    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_ttpci
    budget_ci


    (die core komponenten werden automatisch mitgeladen)


    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


    Danke für die gute Zusammenfassung!
    Eine kurze frage hab ich noch und zwar zu dieser Aussage:


    Zitat

    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.


    Gibt es eine Mplayer Version die FF Karten automatisch erkennt?
    Ich benutze die Version "MPlayer-1.0pre7try2"
    von hier:
    ftp://ftp.mplayerhq.hu/MPlayer/releases/


    gibt es noch aktuellere oder nur die aus dem CVS?
    Ist die CVS Version stabil?


    Danke
    Doggsta

    Asus 7AV880 Mainbaord mit Athlon XP-M; Technotrend DVB-C Karte FF Version 1.6 nur zur Ausgabe; Analog TV Karte; Lorenzen DVB-T Karte; CT-VDR Distribustion mit Kernel 2.6.22.1 und VDR 1.4.7 von eTobi

  • Hallo,


    Unter c't 45 kann ich leider nur bestätigen dass die blacklist (ausgeführt so wie beschrieben) ignoriert wird.
    PS: auch das wechseln des PCI slot bringt nichts. Es wird immer die Buget zuerst
    geladen und dann erhält man mit dem Remote Plugin die "/dev/input/event0 nicht gefunden meldung".

  • schade, ich weiss aber dass das ganze auch unter 4.5 gehen muss, nur weiss ich nicht genau wie das blacklisten geht..


    eine weitere möglichkeit ist mittels modprobe die module zu entladen und neu zu laden (ist in diesem thread weiter oben beschrieben). das passende runvdr file habe ich weiter oben im thread gepostet...


    ist längst nicht so elegant, aber als übergangslösung sehr stabil...

  • Hallo Drew,


    welchen Kernel hast Du installiert? Ist das hotplug-Feature installiert?


    Bis demnächst,
    ARK

    VDR
    ASUS A7N8X-X, AMD 2600+, 2 GB, 320 GB HD, Hauppauge DVB-S 1.3, Hauppauge Nova-S-Plus, Funktastatur
    Debian 4.0/Etch-Kernel 2.6.18-5-486
    c't-VDR 6.1 mit e-tobi 1.6.0 (neu gepatched ohne sortrecordings), acpi, vdradmin-am, burn, osdteletext, ffnetdev, audiorecorder, infosatepg, ...
    Client
    dbox2 (Sagem 2xI_C) mit Neutrino-Derivat

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von ark ()