Ok, habe gerade mal bei mir getestet ... also der Patch wird problemlos ohne Rejects übernommen ... Zur Not komm mal kurz in IRC ...
Gruß,
Space
Ok, habe gerade mal bei mir getestet ... also der Patch wird problemlos ohne Rejects übernommen ... Zur Not komm mal kurz in IRC ...
Gruß,
Space
ZitatAlles anzeigenOriginal von UFO
[..]
Das deutet auf den oben erwähnten HW-Fehler hin, vgl. http://vdrportal.de/board/thre…?postid=870965#post870965
Bei einem Teil der neueren Serie gibt es wohl einen Bestückungsfehler. Fehlerhafte Karten werden lt. Hersteller umgetauscht.
Achtung
1. Nur ein Teil der Karten hat diesen Fehler.
2. Ein Kartentausch löst nur genau dieses Problem, kein anderes!
Um festzustellen, ob die Karte den Fehler hat, würde ich folgt vorgehen:
1. Sicherstellen, daß beide Tuner ein einwandfreies SAT-Signal bekommen.
2. Je eine Aufnahme auf beiden Tunern starten
-> Beiden Aufnahmen müssen ok sein.
3. Aufnahme auf Tuner 2 starten, Tuner 1 macht EPG-Scan
-> Aufnahme ok
4. Aufnahme auf Tuner 1 starten. Tuner 2 macht EPG-Scan
a) Aufnahme ok -> Karte hat den Fehler nicht.
b) Aufnahme hat Artefakte -> Karte hat den Fehler, umtauschen!
Um sicherzugehen, daß es nicht am SAT-Kabel liegt, bitte Test 4 mit vertauschten Antennenkabeln wiederholen.
CU
Oliver
.. ist ziemlich klar ausgedrückt, ja .. genau (und ganz genau) diese sequenz(!) muß so durchgetestet werden.
die karte hier hat den "bug" ..
gruß, ciax
uebrigens... ich habs mal gestern mit windows 7 ausgetestet, und siehe da, da gehts
auch nicht
die karte ansich wird erkannt, aber weder transmmc (dieses scanteil von dvbviewer)
noch progdvb koennen irgendwelche channels scannen. quality steht auf 100 prozent,
aber signal strength auf 0. mehrmaliges rebooten, ausgeschalten lassen etc... hat wie
bei linux auch nichts geholfen. leider kann man bei windows nicht so schoen debuggen
tja, die karte ist wohl doch nichts fuer mich - bzw. meinen rechner
-- randy
ZitatAlles anzeigenOriginal von UFO
Huh?
Die Firmware 15 bzw. 16 kann man z.B. mit meinem Perl-Script aus den .h-Dateien generieren,
vgl. http://vdrportal.de/board/thre…?postid=866680#post866680 .
Welche Firmware geladen werden soll, kann man in "ngene_info_mps2" über ".fw_version" im Treiber einstellen.
CU
Oliver
Moin,
aus welchen .h Dateien (Pfad) meinst Du denn?
Wenn ich nach einer Datei ngene_fw_15.h suche, finde ich die auch nicht. Die muss doch aber die Datei sein, aus der unter anderem extrahiert werden soll?
Vorgehensweise wäre also:
??
Regards
Globber
Auch ich habe eine Karte aus der fehlbestückten Serie erwischt und auch sonst mit dem ganzen Vorhaben HDTV ziemlich ins Klo gegriffen...
Problem 1) Karte verhindert zuverlässig den Shutdown auf ASUS P5N7A-VM. Gleiche Karte in anderem Board macht kein Problem.
Problem 2) fanless 120W Netzteil im Mediagehäuse beisst sich mit der Karte. STV0900 wird nur nach komplett stromlos >1 min des Rechners erkannt. Anderes Netzteil, gleiches Board, gleiche Karte, alles OK
Problem 3) Naja, die erwähnte Fehlbestückung
Zumindest für Problem 3 gibt es ja eine Lösung. Kann man die Fehlbestückung eigentlich auch optisch erkennen? Weiss jemand, was da schief gelaufen ist?
Gruss
plego
ZitatAlles anzeigenOriginally posted by twoofseven
@ abesse:
Ich weiß nicht ob es genau ist, was du suchst und kenne die nachfolgende Historie des von dir genannten Beitrags nicht, jedoch gibt es in vielen DVB-Treibern ein "DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);", welches den Parameter "adapter_nr" definiert, der beim Registrieren eines Adapters als Übergabeparameter erforderlich ist und über den man die Nummern der Adapter manuell bestimmen kann.
Zusätzlich besitzt der nGene-Treiber noch den Parameter "one_adapter", der angibt ob ein oder mehrere Adapter pro Karte registriert werden sollen.
Bsp.
"one_adapter=0" => Zwei Adapter werden angelegt.
"adapter_nr=2,3" => Die beiden Adapter bekommen die Nummern 2 und 3.
=> "/dev/dvb/adapter2" & "/dev/dvb/adapter3" wurden registriert.
Ich hoffe diese Möglichkeit hilft dir weiter.
ich habe nochmals mit einer einzelnen Karte getestet.
Wenn ich "modprobe ngene adapter_nr=0,1" ausführe, dann erscheinen folgende Ausgaben im Kernel log:
DVB: registering new adapter (nGene)
LNBx2x attached on addr=b
DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
stv6110x_attach: Attaching STV6110x
DVB: registering new adapter (nGene)
LNBx2x attached on addr=8
DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...
stv6110x_attach: Attaching STV6110x
Bei "modprobe ngene adapter_nr=1,0" hingegen:
DVB: registering new adapter (nGene)
LNBx2x attached on addr=b
DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...
stv6110x_attach: Attaching STV6110x
DVB: registering new adapter (nGene)
LNBx2x attached on addr=8
DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
stv6110x_attach: Attaching STV6110x
Eine Frage an die Treiberentwickler:
in den Ausgaben erscheint die Ausgabe "LNBx2x attached on addr=b" immer vor "LNBx2x attached on addr=8". Was bedeutet diese Ausgabe?
Entspricht addr=b immer dem Tuner der auf dem Slotblech mit "Tuner 1" gekennzeichnet ist?
Wenn man den Treiber ngene ohne Parameter lädt, kann man dann sicher sein, dass adapter0 immer dem mit "Tuner 1" auf dem Slotblech gekennzeichneten Tuner entspricht?
ZitatAlles anzeigenOriginally posted by abesse
Hallo,
ich verwende mehrere Media-Pointer MP-S2 DVB-S2-Karten in einem System mit den aktuellsten Treibern aus dem git-Repository http://projects.vdr-developer.…/show/mediapointer-dvb-s2 .
Die Reihenfolge der DVB-Karten und der jeweiligen Tuner möchte ich mittels udev-Regeln festlegen, so dass die dvb-Devices beim Booten nicht zufällig verteilt werden. Hierbei bin ich jedoch auf das Problem gestoßen, dass ich nicht für jeden einzelnen Tuner eine udev-Regel erstellen kann, da die einzelnen Tuner die gleichen Attribute besitzen (Ausgabe von Udevinfo für eine Karte siehe Anlage).
folgende Udev-Regel erlaubt es mir nur das dvb-Device für einen Tuner einer bestimmten Karte festzulegen:
SUBSYSTEM=="dvb", ATTRS{vendor}=="0x18c3", ATTRS{device}=="0x0720", KERNELS=="0000:02:00.0",
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter0/%%s $${K#*.}'", SYMLINK+="%c"
Unter http://www.linuxtv.org/piperma…/2009-January/031670.html wurde vor etwa einem Jahr vorgeschlagen für jeden Tuner ein weiteres Attribut zum Treiber hinzuzufügen, so dass die einzelnen Tuner unterschieden werden können.
Nun meine Frage an die Treiberentwickler: wäre es ohne weiteres möglich ein solches Attribut einzubauen, oder gibt es eine sogar schon jetzt eine andere Möglichkeit die Reihenfolge der Tuner mittels udev-Regeln festzulegen?
Das geschilderte Problem mit den udev-Regeln besteht nicht nur bei Verwendung von mehren Dual-Tuner-Karten, sondern auch bei Verwendung nur einer einzelnen Dual-Tuner-Karte. Es scheint nicht möglich zu sein eine udev-Regel für diese Karte zu schreiben, da man nicht zwischen Tuner 0 und Tuner 1 unterscheiden kann.
Weiß jemand wie dies für andere Dual-Tuner-Karten wie Pinnacle PCTV Dual DVB-T Diversity, DViCO FusionHDTV DVB-T Dual Express gelöst wurde? Ein zusätzliches Attribut im Treiber so dass zwischen den Tunern unterschieden werden kann?
ZitatEs scheint nicht möglich zu sein eine udev-Regel für diese Karte zu schreiben, da man nicht zwischen Tuner 0 und Tuner 1 unterscheiden kann.
Die Vergabe der Tuner pro Karte erfolgt statisch und ist durch die I2C-Adressierung im nGene-Treiber festgelegt. "Tuner 0" entspricht dabei dem "unteren" Anschluss beschriftet mit "Tuner 1" und "Tuner 1" entspricht dabei dem "unteren" Anschluss beschriftet mit "Tuner 2".
ZitatWenn man den Treiber ngene ohne Parameter lädt, kann man dann sicher sein, dass adapter0 immer dem mit "Tuner 1" auf dem Slotblech gekennzeichneten Tuner entspricht?
Ja, dies ist auch durch die statische I2C-Adressierung der Tuner im Treiber festgelegt. Deswegen macht es auch IMHO keinen Sinn udev-Regel in Abhängigkeit der einzelnen Tuner zu definieren.
Zitatin den Ausgaben erscheint die Ausgabe "LNBx2x attached on addr=b" immer vor "LNBx2x attached on addr=8". Was bedeutet diese Ausgabe? Entspricht addr=b immer dem Tuner der auf dem Slotblech mit "Tuner 1" gekennzeichnet ist?
Diese Ausgabe erfolgt durch das Modul lnbh24. Die angeführte Adresse bezieht sich auf die I2C Adresse, unter der LNBH24 für den spezifischen Ausgang (insgesamt 2x vorhanden) angesprochen wird.
Gruß,
Matthias
@ twoofseven:
Vielen Dank für die Informationen zur Zuordnung der einzelnen Tuner.
ZitatOriginally posted by twoofseven
abesse:
AFAIK solltest du versuchen die einzelne Karte eindeutig über udev zu identifizieren und dann mit den insmod Optionen in Abhängigkeit der Karte arbeiten.
wenn ich udev richtig verstehe, dann ist das Modul aber schon geladen, bevor die udev-Regeln aktiv wird, Dann ist es aber nicht mehr möglich das Modul mit einem bestimmten Parameter zu laden oder?
ZitatAlles anzeigenOriginal von UFO
[..]
Das deutet auf den oben erwähnten HW-Fehler hin, vgl. http://vdrportal.de/board/thre…?postid=870965#post870965
Bei einem Teil der neueren Serie gibt es wohl einen Bestückungsfehler. Fehlerhafte Karten werden lt. Hersteller umgetauscht.
[..]
CU
Oliver
.. bin mir nicht sicher, ob das schon erwähnt wurde: es handelt sich bei diesem fehler dabei ausschließlich um karten der Revision 5.4 - diese ist auf der print (bestückungsseite) neben dem pci-e stecker zu entdecken (hier: DVB_S2 V5.4).
gruß, ciax
Du hast Recht, Modul Parameter kann man offensichtlich über udev nicht mitgeben. Namen anscheinend jedoch schon (http://www.reactivated.net/writing_udev_rules.html). Leider ist mir bei meinen Versuchen mit zwei Karten und dem Vergleichen der Rückgabe aller "udevadm info -a --name /dev/dvb/adapterX/frontend0", "... /dev/dvb/adapterX/dvr0" und "... /dev/dvb/adapterX/demux0" (X=0...3) auch keine Lösung eingefallen.
Bei dem beschriebenen Vorgehen über die "adapter_nr module option" unter http://www.mythtv.org/wiki/Device_Filenames_and_udev geht man auch davon aus, dass verschiedene Karten mit verschiedenen Modulen geladen werden.
Generell wirst du meiner Meinung nach dieses Problem aktuell jedoch mit jeder zweifachen Dual-Tuner-Konstelation haben. Aber irgendwie kann ich mir auch nicht vorstellen, dass der Kernel die Reihenfolge der Karten beim Abarbeiten der Initialisierung wild auslost, da bei mir immer schön:
erst Karte 1:
looking at device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb0.frontend0':
looking at device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb1.frontend0':
und dann Karte 2:
looking at device '/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/dvb/dvb2.frontend0':
looking at device '/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/dvb/dvb3.frontend0':
geladen wurde.
Ist dies denn bei dir anders?
Gruß,
Matthias
Hallo,
ich habe auch eine Mediapointer mit der Rev. 5.4
Ich habe mal einen Test unter Windows XP gemacht.
Nachdem ich 2 Aufnahmen gestartet habe und nochmal gezappt habe hat sich das ganze System aufgehängt. Nach einem Reboot wurden keine Sender mehr gefunden. Auch Transedit MMC fand keine Sender mehr. Nachdem ich das System stromlos gemacht habe, wurden die Sender wieder gefunden.
Ist die der besagte Bestückungsfehler?
Grüße
[EDIT]
Ich hab jetzt nochmal rumgespielt.
Wird die Aufnahme auf Tuner 1 gestartet und dann auf Tuner 2 Keine Fehler.
Wird die Aufnahme zuerst auf Tuner 2 gestartet und dann auf Tuner 1 umgeschaltet, dann stürzt das Teil ab.
ZitatAlles anzeigenOriginally posted by twoofseven
abesse:
Du hast Recht, Modul Parameter kann man offensichtlich über udev nicht mitgeben. Namen anscheinend jedoch schon (http://www.reactivated.net/writing_udev_rules.html). Leider ist mir bei meinen Versuchen mit zwei Karten und dem Vergleichen der Rückgabe aller "udevadm info -a --name /dev/dvb/adapterX/frontend0", "... /dev/dvb/adapterX/dvr0" und "... /dev/dvb/adapterX/demux0" (X=0...3) auch keine Lösung eingefallen.
Bei dem beschriebenen Vorgehen über die "adapter_nr module option" unter http://www.mythtv.org/wiki/Device_Filenames_and_udev geht man auch davon aus, dass verschiedene Karten mit verschiedenen Modulen geladen werden.
Generell wirst du meiner Meinung nach dieses Problem aktuell jedoch mit jeder zweifachen Dual-Tuner-Konstelation haben. Aber irgendwie kann ich mir auch nicht vorstellen, dass der Kernel die Reihenfolge der Karten beim Abarbeiten der Initialisierung wild auslost, da bei mir immer schön:
erst Karte 1:
looking at device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb0.frontend0':
looking at device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb1.frontend0':
und dann Karte 2:
looking at device '/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/dvb/dvb2.frontend0':
looking at device '/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/dvb/dvb3.frontend0':
geladen wurde.
Ist dies denn bei dir anders?
Bei Verwendung von 2 Dual-Tunern scheint bei mir auch die Reihenfolge der Karten immer gleich zu sein, Wenn jedoch noch eine weitere DVB-Karte (z.B. Technotrend S2-3200) eingebaut ist, dann ist es schon mehrmals vorgekommen, dass die Reihenfolge der Karten vertauscht war.
Das beste wäre, wenn man die einzelnen Tuner der Dual-Tuner Karten mittels udev-Attributen unterscheiden könnte, um so udev-Regeln definieren zu können. Wäre es nicht möglich die von dir beschriebene I2C-Adressierung der Tuner als udev-Attribut verfügbar zu machen?
Ist es richtig, dass die Zuordung von Tuner zum Frontend in ngene.c tuner_attach_stv6110() erfolgt?
@ twoofseven:
mir ist noch eine andere Idee eingefallen wie man das Problem der Zuordnung bei mehren Dual-tunern vielleicht lösen könnte. Und zwar einen zusätzlichen Modul-Parameter zum Treiber hinzuzufügen, der dem PCI-Slot (z.B. 0000:01:00.0) entspricht und dafür sorgt, dass der Treiber beim insmod/modprobe nur für die Karte im angegebenen Slot geladen wird.
Beispiel:
Karte 1 im 1. PCI-Slot (0000:02:00.0)
modprobe ngene adapter_nr=0,1 pci=0000:02:00.0
=> Tuner1 = adapter0
Tuner2 = adapter1
Karte 2 im 2. PCI-Slot (0000:03:00.0)
modprobe ngene adapter_nr=2,3 pci=0000:03:00.0
=> Tuner 1 = adapter2
Tuner 2 = adapter3
ZitatAlles anzeigenOriginal von abesse
@ twoofseven:
mir ist noch eine andere Idee eingefallen wie man das Problem der Zuordnung bei mehren Dual-tunern vielleicht lösen könnte. Und zwar einen zusätzlichen Modul-Parameter zum Treiber hinzuzufügen, der dem PCI-Slot (z.B. 0000:01:00.0) entspricht und dafür sorgt, dass der Treiber beim insmod/modprobe nur für die Karte im angegebenen Slot geladen wird.
Beispiel:
Karte 1 im 1. PCI-Slot (0000:02:00.0)
modprobe ngene adapter_nr=0,1 pci=0000:02:00.0
=> Tuner1 = adapter0
Tuner2 = adapter1
Karte 2 im 2. PCI-Slot (0000:03:00.0)
modprobe ngene adapter_nr=2,3 pci=0000:03:00.0
=> Tuner 1 = adapter2
Tuner 2 = adapter3
So etwas wird nicht funktionieren. U.a. weil man einen Treiber nur einmal laden kann.
Ich verstehe nicht so ganz, wieso unbedingt an den udev-Regeln geschraubt werden muß. Ist doch eigentlich egal, welcher Tuner #1 oder #2 ist.
CU
Oliver
hallo,
großen respekt für die (open-src) entwickler und community! wenn ich mal so frech sein darf (also nicht schlagen, wenn ich als simpler user etwas feedback gebe) :
ZitatAlles anzeigenOriginal von wbreu
Hi,
gibts denn dazu was neues?
Media-Pointer MP-S2 DVB-S2 Twin Tuner (auch als "Low Profile" )
bzw. dazu:
Media-Pointer MP-S2 DVB-S2 Twin Tuner (auch als "Low Profile" )
Die Karte läuft bisher ohne irgendeinen Absturz in dem Rechner.
Aber das Locken und Tunen haut halt nicht sauber hin, dann kommen die entsprechenden TS Continuity-Errors...., wie oben zitiert.
Das alles mit der FW_15.
Sorry, aber die Karte ist so weiterhin unbrauchbar..., Aufnahmen die auf der Karte liefen, haben Fehler noch und noch und Live-TV ist mit Klötzchen-Bildung durch die TS Continuity-Errors auch nicht möglich, da nach kurzer Zeit der Ton weg ist.
Ein weiterhin hoffender
Wolfgang
das problem mit den "TS Continuity-Errors" müßte also an der revision der karten liegen (da gab's eine fehlerhafte bestückung) - Rev. V5.4. die 'vertreiber' der karten (unter welchem synonym auch immer .. mediapoint, mystique, cines2) tauschen die defekten karten.
gibt's zu diesen hinweisen schon neues ?
ZitatOriginal von UFO
Das ist ein noch ungeklärter Fehler und kein Umtauschgrund!
an der firmware (17 od. 15) scheint's für einen "laien" nicht zu liegen?
gibt es überhaupt leute, die mit aktuellem (treiber-)status keine probleme haben? (das GIT müßte ja obsolet sein, nur das HG ist relevant, stimmt's).
womit hängt folgendes zusammen?
ZitatAlles anzeigenOriginal von UFO
Bitte den angehängten Patch einspielen und Test wiederholen.
Wichtig ist für den Test, daß
- der Rechner vor dem Test ausgeschaltet wird und
- VDR nur Tuner 1 verwendet (-D Parameter oder one_adapter=1).
Achtung:
Der Fix hilft nur in genau dieser Situation.
[..]
das müßte also (für einen tuner) gelöst sein, ist das richtig?
ZitatEs gibt noch ähnliche Probleme, wenn beide Tuner verwendet werden. Werde ich mir als nächstes vornehmen...
.. die probleme bestehen noch, nicht wahr?
sorry für das blöde zitieren und nachfragen - hab nur ein wenig den überblick/thema verloren
gruß, ciax
Hi ciax,
sorry, kann dir im Moment nicht weiterhelfen, meine Karte ist gerade auf Reisen.
Wenn ich deine Beschreibungen so lese, => tauschen.
Gruß
Wolfgang
@ abesse:
Kannst du mal folgendes für den ngene ausprobieren:
und für alle anderen dvb-treiber die nachfolgenden Adapternummern manuell angeben:
Dies sollte meiner Meinung nach sicherstellen, dass die Karten immer wieder in der gleichen Reihenfolge angelegt werden.
Gruß,
Matthias
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!