[saubere Lösung] PrimaryDVB Bug?

scovery · 26. Februar 2006

Hi,

habe einen Fehler bei vdrdevel_1.3.43-1 festgestellt (extra nochmal ohne irgend welchen Patches außer den beiden Make kompiliert): ich möchte PrimaryDVB =1 haben und das steht auch so in der setup.conf und das klappt noch beim ersten vdr start. Nur steht dann schon unter den Einstellungen von DVB Primäres DVB Interface 2 (obwohl nach wie vor in der setup.conf 1 steht!). Nach einem vdr restart ist dann PrimaryDVB auf 2 gesetzt.

Kann jemand diesen Bug bestätigen?

Moses123 · 26. Februar 2006

Hallo,

wo siehst Du da einen Bug?

Wenn Du die Reihenfolge der Karten ändern willst, benutze die Suche.

Dann erscheinen da Beiträge, in denen geschrieben ist, wie die Reihenfolge der Treiber zu ändern ist, damit die Reihenfolge der Karten im vdr sich ändert.

Gruß,

Moses123

scovery · 26. Februar 2006

Zitat

Original von Moses123
Wenn Du die Reihenfolge der Karten ändern willst, benutze die Suche.

Dann erscheinen da Beiträge, in denen geschrieben ist, wie die Reihenfolge der Treiber zu ändern ist, damit die Reihenfolge der Karten im vdr sich ändert.

Ahja - und für was gibt's dann die Möglichkeit, das PrimaryDVB zu setzen?
Bei Version 1.3.37 ging's jedenfalls noch.

Brougs78 · 26. Februar 2006

Hi!

Eine 0 in der Setup.conf steht für eine 1 in den DVB-Settings usw., d.h. wenn du das erste Device haben möchtest dann passt das so; möchtest du das zweite Device haben muss eine 1 in der Setup.conf und eine 2 in den DVB-Settings stehen.

Gruß,
Brougs78

scovery · 26. Februar 2006

Zitat

Original von Brougs78
Eine 0 in der Setup.conf steht für eine 1 in den DVB-Settings usw., d.h. wenn du das erste Device haben möchtest dann passt das so; möchtest du das zweite Device haben muss eine 1 in der Setup.conf und eine 2 in den DVB-Settings stehen.

Grrr... Sch...ande

Ich wusste, dass Device 0 und 1 im VDR 1 und 2 heißen - nicht aber dass in der setup.conf wieder 0 und 1 stehen.

Aber irgendwas stimmt trotzdem nicht.

[Edit]
Hier das Log:

Code

Feb 26 20:32:19 localhost kernel: saa7146: register extension 'dvb'.
Feb 26 20:32:19 localhost kernel: ACPI: PCI Interrupt Link [PILA] enabled at IRQ 11
Feb 26 20:32:19 localhost kernel: PCI: setting IRQ 11 as level-triggered
Feb 26 20:32:19 localhost kernel: ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [PILA] -> GSI 11 (level, low) -> IRQ 11
Feb 26 20:32:19 localhost kernel: saa7146: found saa7146 @ mem d098e000 (revision 1, irq 11) (0x13c2,0x0000).
Feb 26 20:32:19 localhost kernel: DVB: registering new adapter (Technotrend/Hauppauge WinTV DVB-S rev1.X).
Feb 26 20:32:19 localhost kernel: adapter has MAC addr = xx:xx:xx:xx:xx
Feb 26 20:32:19 localhost kernel: dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app c000261c
Feb 26 20:32:19 localhost kernel: dvb-ttpci: firmware @ card 0 supports CI link layer interface
Feb 26 20:32:19 localhost kernel: dvb-ttpci: Crystal audio DAC @ card 0 detected
Feb 26 20:32:19 localhost kernel: saa7146_vv: saa7146 (0): registered device video0 [v4l2]
Feb 26 20:32:19 localhost kernel: DVB: registering frontend 0 (Philips TDA8083 DVB-S)...
Feb 26 20:32:19 localhost kernel: dvb-ttpci: found av7110-0.
Feb 26 20:32:19 localhost kernel: saa7146: register extension 'budget dvb'.
Feb 26 20:32:19 localhost kernel: ACPI: PCI Interrupt Link [PILB] enabled at IRQ 10
Feb 26 20:32:19 localhost kernel: PCI: setting IRQ 10 as level-triggered
Feb 26 20:32:19 localhost kernel: ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [PILB] -> GSI 10 (level, low) -> IRQ 10
Feb 26 20:32:19 localhost kernel: saa7146: found saa7146 @ mem d0ad8400 (revision 1, irq 10) (0x13c2,0x1003).
Feb 26 20:32:19 localhost kernel: DVB: registering new adapter (TT-Budget/WinTV-NOVA-S  PCI).
Feb 26 20:32:19 localhost kernel: adapter has MAC addr = xx:xx:xx:xx:xx
Feb 26 20:32:19 localhost kernel: DVB: registering frontend 1 (ST STV0299 DVB-S)...

Alles anzeigen

Die FF ist die erst Karte - warum nimmt VDR aber immer die zweite als Primary? Oder übersehe ich noch was?

scovery · 26. Februar 2006

Hab jetzt gerade nochmal einen Rechner Neustart gemacht. Jetzt hatte sich VDR mal wieder die erst (FF) als Primary ausgesucht. Nach einem VDR Neustart hat VDR (ohne dass irgendwas geändert wurde) aber wieder auf die zweite geändert. Das kann doch so nicht richtig sein. Also für mich ist da was faul

wirbel · 26. Februar 2006

Könnte auch die Reihenfolge des Ladens der Treiber bei dir in der runvdr sein.

kilroy · 26. Februar 2006

Yep. Wenn bei Start die FF Treiber zuerst geladen werden, ist 0 das primary device. Die
Reihenfolge in der runvdr sieht dann z.B. so aus:

Code

lsmod | grep ^dvb_core | awk '{print $4;}' | awk '{ gsub(/,/," ", $1); print }'
dvb_bt8xx dst_ca b2c2_flexcop dvb_ttpci stv0299

Dadurch rutscht die FF an einen anderen Platz.

scovery · 26. Februar 2006

Das sieht bei mir so aus:

Code

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

Aber dann wäre ja die Reihenfolge immer gleich - aber es geht was schief!

Nach dem Rechner-Neustart sagt VDR dass Primary die erst Karte wäre, in der setup.conf steht jedoch PrimaryDVB=1 (was ja dann die zweite wäre, deshalb auch meine anfängliche Verwirrung weil es da gleich lautet). Nach einem VDR Neustart (ohne weitere sonstige Aktion) sagt dann VDR in den Einstellungen Primary wäre die zweite Karte (in der setup. conf steht nach wie vor PrimaryDVB=1).

kilroy · 26. Februar 2006

Wann sieht es bei Dir "so" aus. Nach einem Rechner-Neustart oder vdr-Neustart?

Laut MANUAL fängt die Zählung des Primary DVB Interface bei 1 an:

Code

Primary DVB interface = 1
                         Defines the primary DVB interface (i.e. the one that
                         will display the menus and will react on input through
                         the remote control). Valid values range from '1' to the
                         number of installed DVB cards. If more than one DVB card
                         is installed and a recording is to be started, the
                         program will try to use a free DVB card that is different
                         from the primary DVB interface, so that the viewer will
                         be disturbed as little as possible.

Das deckt sich auch mit meinem System:

Code

grep "PrimaryDVB" /var/lib/vdrdevel/setup.conf
PrimaryDVB = 1

scovery · 26. Februar 2006

Zitat

Original von kilroy
Wann sieht es bei Dir "so" aus. Nach einem Rechner-Neustart oder vdr-Neustart?

Da happert's tatsächlich. Nach einem Rechner-Neustart lautet die Reihenfolge so:

budget budget_core dvb_ttpci

Wenn sofort nach dem Start VDR neu gestartet wird lautet die Reihenfolge so:

dvb_ttpci budget budget_core

Die Frage ist jetzt was das verursacht. Passt da was in der runvdr nicht?

Zitat

Laut MANUAL fängt die Zählung des Primary DVB Interface bei 1 an:[CODE]Primary DVB interface = 1
Defines the primary DVB interface (i.e. the one that
will display the menus and will react on input through
the remote control). Valid values range from '1' to the
number of installed DVB cards.

Stimmt, habe ich auch schon rein gesehen - danach wäre die erste doch 1 (und nicht 0). Aber das ist (hoffentlich?) ein anderes Problem (auch weshalb die Anzeige in VDR nicht mit der von setup.conf überein stimmt).

kilroy · 26. Februar 2006

Ich würde das Problem der runvdr zuschieben, da sie die Reihenfolge vertauscht. Über
dieses Phänomen bin ich auch ab und an gestolpert. Deshalb habe ich einen Menüpunkt
erstellt, der mir die DVB Treiber in der gewünschten Reihenfolge neu lädt und vdr neu
startet.

Im OSD kann ich zwar im DVB Menü die 0 direkt als Primary DVB interface einstellen, mit
den Pfeiltasten ist dies aber nicht möglich. Vielleicht doch ein Käfer?

Nachtrag: Wobei die 0 zwar einstellbar ist aber nicht akzeptiert wird.

scovery · 26. Februar 2006

Zitat

Original von kilroy
Ich würde das Problem der runvdr zuschieben, da sie die Reihenfolge vertauscht.?

Eigentlich sollte da ja nichts anders laufen zwischen Rechner Start und VDR Neustart. Es sei denn dass der Rechner beim Start "mehr beschäftigt" ist?

Die runvdr ist ja schlicht die bei allen c't Distris wohl identische mit dem DVB Modul Teil hier:

Code

function load_dvb_modules()
{
    if modprobe dvb >/dev/null 2>&1 ; then
        get_modulenames
    else
        if [ "$MODULES" ]; then
            for MODULE in $MODULES; do
                modprobe $MODULE >/dev/null 2>&1
            done
        else
            modprobe dvb-ttpci >/dev/null 2>&1 #2.4
            modprobe dvb_ttpci >/dev/null 2>&1 #2.6
            get_modulenames
        fi
        if [ "$KVERS_2_6" ]; then
            wait `pidof udev`
        fi
    fi
    if [ "$KVERS_2_6" ]; then
        sleep 15
    fi
}


function unload_dvb_modules()
{
    for MODULE in $MODULES; do
        rmmod $MODULE >/dev/null 2>&1
        wait `pidof rmmod`
    done
}

Alles anzeigen

Was könnte hier anders gemacht werden?

Klaus' Laden der Treiber in der runvdr sieht schlichter aus, vor allem werden sie nicht beendet und neu geladen:

Code

DVBDIR="../DVB/driver"


LSMOD="`/sbin/lsmod | grep -w '^dvb' | wc -l`"


# Load driver if it hasn't been loaded already:
if [ $LSMOD -eq 0 ] ; then
   (cd $DVBDIR; make insmod)
   fi

Edit: kilroy, steht ja hier schon was darüber

scovery · 26. Februar 2006

Jetzt wird's glaube ich etwas klarer.

Habe dvb_ttpci, budget und budget_core jetzt in /etc/hotplug/blacklist eingetragen und jetzt wird nur noch der FF-Treiber geladen. In der runvdr werden die Budget-Treiber ja gar nicht berücksichtigt und dort lediglich der dvb_ttpci Treiber geladen bzw. erneut geladen. Somit ist natürlich klar dass sich bei einem restart die Reihenfolge ändert.

Ist also schon ein kleiner Käfer - nicht in vdr sondern in der runvdr der c't Distri.

Vielleicht klärt sich auch noch der Widerspruch in der Karten-Nummerierung auf.

Edit: äh, ne, wird doch nicht klarer. Hatte function get_modulenames() übersehen, die ja alle dvb_core Module lieferen müsste
Warum wird bei Ausschluss von dvb_ttpci, budget und budget_core in der Blacklist dvb_ttpci doch geladen, wenn nur budget und budget_core ausgeschlossen werden nicht Das ist ja ziemlich seltsam.

Moses123 · 27. Februar 2006

Zitat

Original von scovery

Ahja - und für was gibt's dann die Möglichkeit, das PrimaryDVB zu setzen?
Bei Version 1.3.37 ging's jedenfalls noch.

Hallo,

die Wahl des Primary Device wird nach meinem Verständnis nur nötig, wenn Du mehr wie eine FF- Karte hast, damit Du festlegen kannst, auf welcher Karte das OSD erscheint. Wenn Du eine Budget als Primary angibst sucht er automatisch die nächste Karte, die ein OSD kann und die wird zum Primary Device.
Durch die Änderung der Treiberreihenfolge beim Laden, wie Du ja später auch beschrieben hast, verändert sich eben der Eintrag.

Ich habe bei mir die Buget (Twinhan) z. Bsp. durch das Laden derer Treiber in der modules.conf als erste Karte festgelegt, die FF wird die zweite und damit ist bei mir das Primary Device die 2.

Gruß,
Moses123

kilroy · 27. Februar 2006

Moses123: Mit den zwei FF Karten hast Du Recht. vdr nimmt die erste FF Karte als Primary
DVB interface. Wenn keine FF Karte vorhanden ist, wird der Wert auf 1 gesetzt:

Code

Feb 27 11:20:09 zaphod vdr: [9333] ERROR: invalid primary device number: 2
Feb 27 11:20:09 zaphod vdr: [9333] ERROR: no primary device found - using first device!
Feb 27 11:20:09 zaphod vdr: [9333] setting primary device to 1

Bei mir ergab sich das Problem, daß nicht immer die richtige FF Karte als Primary DVB
interface genommen wurde. Wenn die budget Module vor dvb_ttpci geladen wurden,
ergab sich auch mal 3 oder 4 als Primary DVB interface...

scovery: Wenn Du dvb_ttpci, budget und budget_core in der blackilist hast und es auch
nicht selbst oder über /etc/modules lädst, wird dvb_ttpci von runvdr geladen. Module für
budget Karten werden nicht geladen. Ich würde vorschlagen, du trägst alle Module in die
blacklist ein und lädst sie dann in definierter Reihenfolge (FF zuerst) per /etc/modules:

Code

cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file should contain the names of kernel modules that are
# to be loaded at boot time, one per line.  Comments begin with
# a "#", and everything on the line after them are ignored.


ppdev
dvb_ttpci
b2c2_flexcop_pci
bttv
dvb-bt8xx
nvram

Alles anzeigen

scovery · 27. Februar 2006

Zitat

Original von kilroy
scovery: Wenn Du dvb_ttpci, budget und budget_core in der blackilist hast und es auch
nicht selbst oder über /etc/modules lädst, wird dvb_ttpci von runvdr geladen.

Ganz bin ich durch die "runvdr" nicht durchgestiege (weil wenn ich nur budget und budget_core "blackliste" dvb_ttpci nicht geladen wird, wenn ich sie ausschließe schon). Aber sei's drum...

Zitat

Ich würde vorschlagen, du trägst alle Module in die
blacklist ein und lädst sie dann in definierter Reihenfolge (FF zuerst) per /etc/modules

Habe jetzt alle drei Module in der Blacklist und lade sie nun explizitnacheinander in der runvdr. Jetzt bleibt die Reihenfolge gleich (wird ja auch beim erneuten Laden durchlaufen und dann steht alles in der gewünschten Reihenfolge an einer Stelle).

Danke für die Mithilfe.

scovery · 1. März 2006

Vielleicht wäre das wie ich's jetzt gemacht habe die saubeste Lösung für die runvdr.

Problem ist, dass im String $MODULES die zuerst geladenen DVB Module hinten stehen, in der FOR-Schleife aber die zuletzt geladenen als erstes erneut geladen werden. Deshalb habe ich die Reihenfolge getauscht.

Aus

Code

for MODULE in $MODULES; do
     modprobe $MODULE >/dev/null 2>&1
done

habe ich das gemacht:

Code

for MODULE in $MODULES; do
     MODULES_INVERS="$MODULE $MODULES_INVERS"
done
for MODULE in $MODULES_INVERS; do
     modprobe $MODULE >/dev/null 2>&1
done

Damit ist die Reihenfolge bei einem vdr restart genauso wie beim automatischen Laden beim Rechnerstart.

[saubere Lösung] PrimaryDVB Bug?

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema