Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.
Nun meine Frage:
Fehlt für das GRAB Kommando nur der Code im Plugin oder auch Code im Kerneltreiber?
Ja, das weiß ich. Ich möchte ja auch nur wissen, ob nur der Code im Plugin fehlt oder der Code dort nicht implementiert ist, weil der dazu benötigte Code im Kerneltreiber noch nicht existiert. Im zweiteren Fall wäre die Implementation aufwendiger.fehlt im plugin siehe:Nun meine Frage:
Fehlt für das GRAB Kommando nur der Code im Plugin oder auch Code im Kerneltreiber?
http://powarman.dyndns.org/hgwebdir.cgi/…dffdevice.c#l97
Sind wirklich vier Adern nötig
Quoted
Oder kennt jemand eine Quelle?

Interessant wäre noch, ob im Fehlerfall Ausschriften der Art "demux_worker 2 TS: FE A3 47 44 2B A1 E6 5D" im syslog erscheinen, wobei die konkreten Werte natürlich unterschiedlich sind.
|
|
Source code |
1 |
[11194.049488] demux_worker 3 TS: CF 60 47 44 9F 4E 97 B5 |
|
|
Source code |
1 2 3 4 5 6 7 8 9 |
... [14230.335549] demux_worker: called but nothing to do [14439.517803] demux_worker 3 TS: 20 2D 20 47 07 80 D4 2D [14608.530800] demux_worker: called but nothing to do ... [21412.686816] demux_worker: called but nothing to do [21432.830240] demux_worker 3 TS: 13 47 BB 0B 14 DC 10 31 [21433.023811] demux_worker: called but nothing to do ... |
Wieso braucht der FB-Empfänger einen 4-poligen Stecker? Sind wirklich vier Adern nötig?
Verlängerungskabel sind dafür nicht zu bekommen. Oder kennt jemand eine Quelle?
|
|
Source code |
1 2 3 |
-D NUM, --device=NUM use only the given DVB device (NUM = 0, 1, 2...)
there may be several -D options (default: all DVB
devices will be used)
|
fehlt im plugin siehe:Nun meine Frage:
Fehlt für das GRAB Kommando nur der Code im Plugin oder auch Code im Kerneltreiber?
Nur zur Info:fehlt im plugin siehe:Nun meine Frage:
Fehlt für das GRAB Kommando nur der Code im Plugin oder auch Code im Kerneltreiber?
http://powarman.dyndns.org/hgwebdir.cgi/…dffdevice.c#l97Ja, das weiß ich. Ich möchte ja auch nur wissen, ob nur der Code im Plugin fehlt oder der Code dort nicht implementiert ist, weil der dazu benötigte Code im Kerneltreiber noch nicht existiert. Im zweiteren Fall wäre die Implementation aufwendiger.
Ok. Ich habe Antwort vom Entwickler erhalten. Die relevanten Teile fehlen auch noch im Kernel-Treiber.
|
|
Source code |
1 |
dvb-ttpremium-fpga-01.fw.105 |
Ja, die Extension '105'muss noch weg! Die Datei muss auf *.fw enden, da sonst der Treiber den eventuell vorhandenen alten Stand lädt. Siehe Code-Schnipsel aus dem Treiber:Ist das richtig? Muss man die Datei dann noch umbennen?
|
|
Source code |
1 2 3 4 |
70 /* request the FPGA firmware, this will block until someone uploads it */
71 ret = request_firmware(&fw, "dvb-ttpremium-fpga-01.fw", &saa716x->pdev->dev);
72 if (ret) {
73 if (ret == -ENOENT) {
|
This post has been edited 1 times, last edit by "Steve135" (May 13th 2011, 12:54pm)
also hier ist es aehnlich. ich habe immer orfhd als ersten sender eingestellt, der nach dem booten erscheint.@Copperhead:
Danke für den Link. Habe das 'alternative' Plugin mal ausprobiert, es ändert aber leider an der Problematik bei mir nichts. Es verhält sich diesbezüglich genau wie das Original-Plugin. Nach einem 'Cold-Boot' ist auch wie beim Original-Plugin der erste Tuner immer verpixelt. Sobald ich den VDR beende und zum zweiten mal starte funktioniert es. Das ist schon ein wenig blöd. Ich kann doch nicht immer bei jedem Rechner Start einmal vorher den VDR 'weg-killen' damit ich sicher sein kann, dass meine Aufnahmen auch gelingen und der Tuner keinen Pixelmüll produziert.![]()
Vielleicht haben powarman und UFO ja doch noch eine 'Eingebung', an was das liegen könnte...
Gruss Steve
Quoted
Die neue FPGA Firmware 1.05 (dvb-ttpremium-fpga-01_v1_05.zip) erlaubt es zusammen mit einer Änderung im Treiber einen sauberen Reset des Demodulators auf der Karte durchzuführen. Dies geschieht automatisch beim Laden des Treibers.
Quoted
saa716x_ff: Do an explicit demodulator reset.
When loading the driver an explicit hardware reset of the demodulator is now
done using the FPGA. FPGA firmware version 1.05 is needed for this to work.
Hatte es ja gestern Abend schon bei mir installiert, bin aber bisher leider noch nicht zum Test gekommen. Ab und zu muss man doch auch noch arbeiten und hat so nicht genügend Zeit für die 'wichtigen' Dinge...Evtl. hilft die neue FPGA FW zusammen mit dem Treiberupdate von gestern Abend?
Sobald ich es getestet habe, gibt's natürlich auch von mir eine Rückmeldung dazu ob das Problem damit 'gefixed' ist.
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
[ 26.362652] saa716x_pci_init (0): found a Technotrend S2 6400 Dual S2 Premium PCIe card [ 26.362742] SAA716x FF 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 26.362747] SAA716x FF 0000:01:00.0: setting latency timer to 64 [ 26.362922] alloc irq_desc for 30 on node -1 [ 26.362923] alloc kstat_irqs on node -1 [ 26.362934] SAA716x FF 0000:01:00.0: irq 30 for MSI/MSI-X [ 26.362958] SAA7160 Rev 2 [13c2:300a], irq: 30, [ 26.362959] mmio: 0xffffc90021c00000 [ 26.362961] SAA7160 64Bit, MSI Enabled, MSI-X=32 msgs [ 26.368054] saa716x_i2c_hwinit (0): Adapter (b000) SAA716x I2C Core 0 RESET [ 26.368332] saa716x_i2c_hwinit (0): Adapter (c000) SAA716x I2C Core 1 RESET [ 26.469008] SAA716x FF 0000:01:00.0: firmware: requesting dvb-ttpremium-fpga- 01.fw [ 27.591032] SAA716x FF FPGA version 1.05 [ 27.591038] SAA716x FF 0000:01:00.0: firmware: requesting dvb-ttpremium-loade r-01.fw [ 27.592863] SAA716x FF loader version 1.03 [ 27.871549] SAA716x FF 0000:01:00.0: firmware: requesting dvb-ttpremium-st710 9-01.fw [ 28.270664] saa716x_get_offset (0): Offset @ 200 [ 28.270668] DVB: registering new adapter (SAA716x dvb adapter) [ 28.375543] stv6110x_attach: Attaching STV6110x [ 28.378606] DVB: registering adapter 0 frontend 0 (STV090x Multistandard)... [ 28.378724] DVB: registering new adapter (SAA716x dvb adapter) [ 28.378996] stv6110x_attach: Attaching STV6110x [ 28.410230] DVB: registering adapter 1 frontend 0 (STV090x Multistandard)... [ 38.410010] saa716x_ff_pci_probe (0): timed out waiting for boot finish [ 38.411111] SAA716x FF 0000:01:00.0: PCI INT A disabled [ 38.411116] SAA716x FF: probe of 0000:01:00.0 failed with error -1 |
|
|
Source code |
1 |
saa716x_enable_msix (0): MSI-X request failed <-22> |
Was ist denn eigentlich der Unterschied zwischen MSI und MSI-X?
Ich hatte bei mir ein ähnliches Probelm. Nur entstanden die Artfekate erst beim Umschalten zwischen den Frontends. Wenn ich von SD- auf HD-Kanäle umgeschaltet hab, war der Fehler nicht zu sehen. Erst bei einer Aufnamhe oder beim Wechslen der FEs auf einem HD-Sender per femon traten die Fehler auf.Wenn ich dann mehrfach zwischen einem (HD)-Sender mit Artefakten und einem Sender ohne Artefakte wechsle, dann fängt sich das System oft irgendwann und beide Tuner funktionieren ab dann korrekt. Wenn ich auf einem Tuner Artefakte habe und auf einem beliebigen Sender dieses Transponder eine Aufnahme starte, so ist diese Aufnahme auch defekt und hat somit auch Artefakte. SD-Sender sind von der Problematik genauso betroffen, zeigen aber eine deutlich geringere Menge von Artefakten als die HD-Sender.
|
|
Source code |
1 |
maxcpus=2 |