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

  • Zusammenfassung/Lösung hier gelöst: Probleme mit FB beim restart/Reihenfolge der DVB Karten festlegen

    Hi,

    Ich habe ein System mit einer Nexus und einer Nova karte.

    Mein VDR betrachtet die Nova als Device1 und die nexus als device2, wass dann immer zu sowas führt:

    Apr 29 09:20:08 localhost vdr: [6085] setting primary device to 1
    Apr 29 09:20:08 localhost vdr: [6085] device 1 has no MPEG decoder
    Apr 29 09:20:08 localhost vdr: [6085] trying device number 2 instead
    Apr 29 09:20:08 localhost vdr: [6085] setting primary device to 2

    Im Prinzip ist das ja kein problem, allerdings kommt es beim vdr restart öfter vor dass die Fernbedienung (Nexus FB mit Remote Plugin) nicht mehr funktioniert. Ich vermute dass das damit zu tun hat.

    Kann man VDR sagen welche Karte Device1 und welche Device2 sein soll? Oder kann man evtl. die Reihenfolge in der die treiber für nexus und Nova geladen werden ändern? oder kennt jemand eine andere lösung für mein problem (tauschen der PCI slots ist eher schlecht).?

    Auch würde mich interresieren wie ich die Nova Karte temporär deaktiviren kann (wenn mir mal nur ein Sat kabel zur verfügung steht).

    Vielen Dank im vorraus !

    4 Mal editiert, zuletzt von allow (18. Juni 2006 um 09:00)

  • Du müsstest die Reihenfolge beim Laden der DVB-Module umbiegen... Áber warum setzt du im VDR/Einstellungen/DVB nicht einfach das primary device standardmässig auf 2? Dann versucht der vdr schon gar nicht das device 1 zu nehmen.

    Joe

    Meine VDR

    VDR-Server: Xeon E-2278G, Debian 12 in QEMU VM, vdr 2.7.3, Digital Devices Max SX8, Plugins: dummydevice 2.0.0, live 3.3.5, iptv 2.4.0 (patched), streamdev 0.6.3, svdrposd 1.0.0, timeserver 1.0, ffmpeg 5.1.5, mplayer (UNKNOWN-12 :) aus Debian 12)

    VDR1/2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, vdr 2.7.3, softhdodroid, svdrpservice, remoteosd, satip, timeserver 1.0, iptv 2.4.0 (patched)
    VDR3: Odroid N2+ mit VDRSternELEC (Testphase)

  • Hoi

    du kannst auch die 2 Karten in den Slot tauschen, dann sollte er die Nexus auch zuerst erkennen.

    Dirk

    Meine Signatur

    :]Heute ist nicht alle Tage, ich schreib wieder, keine Frage :]
    VDR1: Silverstone LC14M, AMD X2-BE2350,2GB/1,5TB,DVB-s/s2/c,Gentoo,Kernel 3.8.5,VDR-2.0.0
    VDR2: Silverstone GD05B, Intel G2020, Asrock B75-Pro3M, Asus GT610/2G, 8GB/1TB, YAVDR 0.5
    VDR3: Silverstone ML03, Intel G2020, Asrock B75-R2, 8GB/1TB

  • Slots tauschen ist schlecht (habe ich ja schon geschrieben). Wenn ich die einstellung im Menü ändere erhalte ich folgendes:

    Apr 29 10:22:33 localhost vdr: [4887] setting primary device to 2
    Apr 29 10:22:33 localhost vdr: [4887] device 2 has no MPEG decoder
    Apr 29 10:22:33 localhost vdr: [4887] trying device number 1 instead
    Apr 29 10:22:33 localhost vdr: [4887] setting primary device to 1

    macht irgendwie keinen sinn, aber ist so...

    Meine FB geht nach einenem vdr restart auch weiterhin nicht...

    Einmal editiert, zuletzt von allow (29. April 2006 um 10:27)

  • versuch die module manuell einzubinden

    wie das bei c't vdr geht, kann ich dir aba auch ned sagen

    das is meine Reihenfolge:

    normal werden ves1x93 und stv0299 von selbst eingebunden, ich hab es zu sicherheit nochmal dahinter gesetzt

    Dirk

    Meine Signatur

    :]Heute ist nicht alle Tage, ich schreib wieder, keine Frage :]
    VDR1: Silverstone LC14M, AMD X2-BE2350,2GB/1,5TB,DVB-s/s2/c,Gentoo,Kernel 3.8.5,VDR-2.0.0
    VDR2: Silverstone GD05B, Intel G2020, Asrock B75-Pro3M, Asus GT610/2G, 8GB/1TB, YAVDR 0.5
    VDR3: Silverstone ML03, Intel G2020, Asrock B75-R2, 8GB/1TB

  • Interessant wäre auch die von dir eingesetzte Kernelversion, denn die Module müssen bei 2.4 oder 2.6 jeweils in anderen Konfigurationsdateien eingetragen werden um die Reihenfolge festzulegen.

    Bei 2.6 sind die Module in /etc/modules in der erforderlichen Reihenfolge ohne modeprobe einzutragen (siehe Dirks Posting). Für Kernel 2.4 habe ich die Einstellungen leider nicht zur Hand, war aber wenn ich mich recht erinnere eine Datei in /etc/modutils ...

    <edit>
    Hinweis bezüglich modeprobe hinzugefügt.

    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 (29. April 2006 um 10:57)

  • Moin,

    das Problem mit der nicht funktionierenden FB nach einem Restart habe ich so gelöst:

    1. Änderung in der /usr/sbin/runvdrdevel:
    .
    .
    .
    function get_modulenames()
    {
    if [ "$KVERS_2_6" ]; then
    # MODULES=`lsmod | grep ^dvb_core | awk '{print $4;}' | awk '{ gsub(/,/," ", $1); print }'`
    # [ "$MODULES" ] && MODULES="$MODULES dvb_core"
    MODULES="dvb-ttpci dvb_core budget-ci budget-core b2c2-flexcop-pci b2c2-flexcop dvb_core"
    else
    MODULES=`lsmod | grep dvb-core | cut -d'[' -f2 | cut -d']' -f1`
    [ "$MODULES" ] && MODULES="$MODULES dvb-core"
    fi
    }
    .
    .
    .
    VDR_ERR=`mktemp -p /tmp vdrdevel-err.XXXXXX`

    get_modulenames
    load_dvb_modules
    .
    .
    .
    2. Verhindern das die Module schon beim Hochfahren geladen werden.
    Wenn Du udev verwendest, dann noch in der /etc/modprobe.d/blacklist um die Module Deiner Karten erweitern:

    Bsp:
    blacklist dvb_core
    blacklist dvb_ttpci
    blacklist budget_ci
    blacklist budget_core
    blacklist b2c2_flexcop_pci
    blacklist b2c2_flexcop

    oder bei Verwendung hotplug die Datei /etc/hotplug/blacklist

    dvb_core
    dvb_ttpci
    budget_ci
    budget_core
    b2c2_flexcop_pci
    b2c2_flexcop

    Das ganze hat aber den Nachteil das die /usr/sbin/runvdrdevel mit jeder neuen Version überschrieben wird und Du die Änderungen jedesmal neu einpflegen musst.

    Ich hoffe das hilft Dir weiter

    Gruß Thomas

    Server: yaVDR 0.5 stable, MB=ASRock P5B-DE, CPU=E7500 1,9GHz, RAM=2GB, Grafik=GeForce 9500GT, DVB=2xDVBSky S952, 1xTT-Budget S2-3200, HDD=Transcend 8GB SSD, WDC 1TB, Samsung 1,5TB, DVD=LG GH22NS50, Remote=Harmony 300 an DVBSky
    Client1: yaVDR 0.5 stable MB=MSI 865PE Neo2-V, CPU=P4 2,8GHz, RAM=512MB, Grafik=GeForce GT610, DVB=none, HDD=ST3500630AS 450GB, DVD=LG GSA-4163B, Remote=MCEUSB

  • ich habs jetzt mal mit umstecken in den PCI slots probiert, aber ohne erfolg:

    Bei manchen Varianten geht die FB gar nicht, und bei anderen geht sie, aber wie oben beschrieben nur bis ich den vdr restarte...

    Da anderen Lösungen werde ich am WE testen. Auf jedenfall schonmal vielen Dank !!

  • vielen Dank ThomasHS, dein Tip hat mein Problem gelöst.

    wenn mir jetzt noch jemand der mit grep und awk vertraut ist die zeilen

    # MODULES=`lsmod | grep ^dvb_core | awk '{print $4;}' | awk '{ gsub(/,/," ", $1); print }'`
    # [ "$MODULES" ] && MODULES="$MODULES dvb_core"

    erklären könnte (ich weiss immer ganz gern was genau ich da mache, und ich bin mir nicht ganz im klaren über die arbeitsweise der beiden ersetzten zeilen...)

    Einmal editiert, zuletzt von allow (30. April 2006 um 10:41)

  • Probier es einfach aus, gib die Befehle in einer shell ein und beobachte was passiert.
    Die Zeile MODULES=... bildet eine Shellvariable, die kannst du anschliessend mit echo ausgeben. Z.B.:

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

    und die Befehle die verwendet werden, kannst du auch einzeln einsetzen.

    lsmod listet alle geladenen Module
    grep ^dvb_core sucht in dieser Ausgabe nach einer Zeile die mit dvb_core beginnt
    awk '{print $4;}' wiederum zerlegt die Ausgabe von grep in ihre Einzelteile (bei den Trennzeichen) und gibt die "vierte Spalte" aus
    usw... versuch einmal

    Code
    echo 111 222 333 444 555 | awk '{print $4;}'

    damit du siehst wie das funktioniert.

    <edit>
    Wenn du die blacklist-Einträge schon vorgenommen hast, probier einmal aus ob du nicht ohne Änderung der runvdrdevel auskommst, das funktioniert bei mir, wenn die benötigten module in /etc/modules eingetragen werden. Das erspart die Anpassung der runvdrdevel bei einem Update...

    /etc/modules

    Code
    dvb_core
    dvb_ttpci
    budget_ci
    budget_core

    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

    2 Mal editiert, zuletzt von geeg07 (30. April 2006 um 12:41)

  • danke für die erklärung und den tip werde ich mal probieren sobald ich meine restlichen probleme mit der 4.5er version in den griff bekommen habe:-)

  • Zitat

    b2c2_flexcop_pci
    b2c2_flexcop


    die brauchst du für deine aktuelle Konfiguration nicht, die werden bspw. für die Karten SkyStar u. Airstar benötigt.

    + seaman

    gerade kein vdr am laufen

  • danke, dann nehm ich die raus...

    leider hat es mit der original runvdr nicht funktioniert (altes Problem ist wieder da).

    Sonst noch ideen für eine solide dauerhafte lösung?

  • Zitat

    Original von allow
    leider hat es mit der original runvdr nicht funktioniert (altes Problem ist wieder da).

    Wenn du die Einträge in /etc/modules vornimmst, funktioniert es nicht?

    <edit>
    Möglicherweise hilft es, wenn du nach dem Ändern von /etc/modules noch update-modules aufrufst. Dann sollten nach einem Neustart die Treiber in der korrekten Reihenfolge geladen werden...

    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 (30. April 2006 um 17:07)

  • hab alles probiert, aber das problem liegt anscheinend nicht beim ersten laden der modules, sondern beim neuladen beim restart des vdr, und daher kommt man um das geänderte script wohl nicht rum...

  • Hallo,

    ich hatte/habe gerade ähnliches Problem mit einer Nova-S, welche als
    Budget-CI erkannt wird und daher kein Kanal verfügbar war.
    Unter 2.4.27 (ctvdr3) habe ich es wie folgt gelöst:

    in /etc/modules folgendes hinzufügen

    Code
    dvb-ttpci-budget

    -> Reboot -> DVB-Karte wird korrekt erkannt
    update-modules
    den unteren Part in /etc/modules.conf entfernen

    Danach kann auch das 'dvb-ttpci-budget' aus der /etc/modules wieder raus.

    Lag wohl daran, daß vorher ne Nova-T installiert war.

    Obwohl ich mit o.g. Nova-S auch Probleme bei ct-VDR4.5 (Kernel2.6.15) habe,
    das könnte aber auch mit der em8300 Karte zusammenhängen ... Darum kümmer ich mich als nächstes ...

    Gruß, Aman

    Signatur ist in Überarbeitung

  • So, nun habe ich die 2te. Nova-S eingebaut, aber ich habe nun das
    gleiche Problem wie allow, nach einem Restart des vdr, werden 1 oder beiden Karten nicht erkannt.

    Karte 1: Nova-S Rev. 1.1 - Platine grün - kein CI- dvb-ttpci-budget
    Karte 2: Nova-S Rev. 1.0 - Platine braun - kein CI nur Vorbereitung - dvb-ttpci-budget-ci

    Ich muß in folgender Reihenfolge die Karten 'mounten', ansonsten
    wird Karte 2 nicht erkannt & Karte 1 als -CI erkannt & funzt nicht:

    modprobe oder als Eintrag in die /etc/modules:
    dvb-ttpci-budget
    dvb-ttpci-budget-ci

    Dann vdr starten werden beiden Karten korrekt erkannt, restarte ich den
    vdr aus dem OSD oder er verschluckt sich & restartet selbst, tritt wieder o.g. Problem auf.

    Habe jetzt erstmal in der /usr/sbin/runvdr folgende Zeile hinzugefügt:

    Code
    modprobe dvb-ttpci-budget
    sleep 2
    modprobe dvb-ttpci-budget-ci


    Aber gibt es nicht eine elegantere Lösung ?
    Denn mit einem vdr-Update müßte ich die Zeilen erneut hinzufügen

    Gruß, Aman

    Signatur ist in Überarbeitung

Jetzt mitmachen!

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