Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

gda · 8. Februar 2013

Wieder diese Lücke, 3 Sekunden lang und das passiert für jeden Adapter:

Zitat von seahawk1986

Code

[   15.027218] DRXK driver version 0.9.4300
[   15.079534] drxk: frontend initialized.
[   17.123029] DVB: registering new adapter (nGene)
[   17.123045] ngene 0000:02:00.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)...

Was passiert denn da in dieser Zeit? Von UFO werde ich kaum eine Antwort bekommen, der ignoriert mich, der Ignorant ;).
Wie wäre es mit jasminj?

Upps, ich meinte eigentlich diese:

Code

[   17.154611] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[   20.113856] DRXK driver version 0.9.4300

Das Andere sind ja nur 2 Sekunden, aber nicht minder interessant.

Gerald

seahawk1986 · 8. Februar 2013

Und hier noch einmal mit debug-Ausgaben von drxk:
http://paste.ubuntu.com/1625189/
Die Pausen sind zum einen beim DownloadMicrocode - ist das das Laden der Firmware?

Code

[   19.271527] drxk: load_microcode
[   19.271614] drxk: DownloadMicrocode
[   22.125606] drxk: DRXX_Open

Und zum anderen jeweils bei

Code

[   17.141743] drxk: HI_Command
[   19.171192] drxk: drxk_gate_ctrldisable

gda · 8. Februar 2013

Ich habe mir schon gedacht. dass das mit dem Firmware-Upload zu tun haben könnte, aber muss das wirklich so lange dauern?

Gerald

seahawk1986 · 8. Februar 2013

Dauert es denn bei deinem Flex-Modul so lange?

jasminj · 8. Februar 2013

Zitat von gda

Was passiert denn da in dieser Zeit? Von UFO werde ich kaum eine Antwort bekommen, der ignoriert mich, der Ignorant ;).
Wie wäre es mit jasminj?

Die steckt bis über beide Ohren in was anderem und will sich eigentlich mit dem CI/CAM weiter beschäftigen.
Sie hat auch keine HW um das nach zustellen und überhaupt keinen Tau, was da passieren könnte, weil sie sich diesen Teil noch niemals angesehen hat und keine Vermutungen anstellt, ohne etwas zu wissen ...

Zitat von gda

Ich habe mir schon gedacht. dass das mit dem Firmware-Upload zu tun haben könnte, aber muss das wirklich so lange dauern?

Nun, wenn man bei der CineS2 auch SW laden muss, was ich ja nicht weiß, dann könnte ich das nachwassern, allerdings erst nachdem mein CI/CAM 100%ig funktioniert. Mir ist wichtiger es geht überhaupt etwas und langsam, als unzuverlässig.

S:oren · 8. Februar 2013

Zitat von gda

Wieder diese Lücke, 3 Sekunden lang und das passiert für jeden Adapter:

Was passiert denn da in dieser Zeit?

Normalerweise die Initialisierung des Tuners vor dem DRXK-Demod. Das war aber im Logfile geloescht...

Zitat von gda
Upps, ich meinte eigentlich diese:
Code
[   17.154611] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[   20.113856] DRXK driver version 0.9.4300

Das ist der Download der Firmware. Da gab es mal ein Problem bei synchronem Laden der Firmware bei der Device-Erkennung, die ab einer Version von udev in einen Timeout laeuft. Deshalb kann der Kernel neuerdings Firmware selbst laden (und drxk laedt asynchron, was in der Kombi wenig Sinn macht)...

Gruss,
S:oren

UFO · 9. Februar 2013

Zitat von seahawk1986

Dauert es denn bei deinem Flex-Modul so lange?

Welcher Kernel, welche udev-Version?

In neueren udev-Versionen ist der FW-Upload (während des Ladens der Treiber) "broken". Soweit ich es damals mitbekommen habe, hält der udev-Maintainer dies für richtig und normal, wofür er sich - zu Recht - den Zorn von Linus eingefangen hat. Die neuesten Kernel laden Firmware daher nun direkt - ohne udev. Bin allerdings nicht auf dem laufenden, ob und was sich in letzter Zeit in dieser Sache getan hat.

Abhilfe, wahlweise:
- Treiber blacklisten und später per Skript laden.
- Ältere udev-Version verwenden.
- Neueren Kernel verwenden.

Edit:
Bei mir sieht es so aus - mit ein paar zusätzlichen Ausgaben in load_microcode():

Code

Feb  9 05:06:34 darkstar kernel: [  721.269131] drxk: status = 0x639130d9
Feb  9 05:06:34 darkstar kernel: [  721.269196] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
Feb  9 05:06:34 darkstar kernel: [  721.292265] load_microcode vor request
Feb  9 05:06:34 darkstar kernel: [  721.299137] load_microcode download
Feb  9 05:06:34 darkstar kernel: [  721.668978] load_microcode release
Feb  9 05:06:34 darkstar kernel: [  721.669049] load_microcode fertig
Feb  9 05:06:34 darkstar kernel: [  721.705103] DRXK driver version 0.9.4300
Feb  9 05:06:34 darkstar kernel: [  721.711404] drxk: frontend initialized.
Feb  9 05:06:36 darkstar kernel: [  723.392432] DDBridge 0000:05:00.0: DVB: registering adapter 4 frontend 0 (DRXK DVB-C DVB-T)...


Feb  9 05:06:36 darkstar kernel: [  723.401130] drxk: status = 0x639130d9
Feb  9 05:06:36 darkstar kernel: [  723.401195] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
Feb  9 05:06:36 darkstar kernel: [  723.420242] load_microcode vor request
Feb  9 05:06:36 darkstar kernel: [  723.427095] load_microcode download
Feb  9 05:06:37 darkstar kernel: [  723.791517] load_microcode release
Feb  9 05:06:37 darkstar kernel: [  723.791588] load_microcode fertig
Feb  9 05:06:37 darkstar kernel: [  723.829049] DRXK driver version 0.9.4300
Feb  9 05:06:37 darkstar kernel: [  723.835381] drxk: frontend initialized.
Feb  9 05:06:38 darkstar kernel: [  725.516474] DDBridge 0000:05:00.0: DVB: registering adapter 5 frontend 0 (DRXK DVB-C DVB-T)...

Alles anzeigen

D.h. bei mir gibt es diese Verzögerung beim Laden der Firmware nicht. Ich werde es jedoch noch einmal mit einer ngene-Bridge kontrollieren.

CU
Oliver

UFO · 9. Februar 2013

<OT>

Zitat von gda

Was passiert denn da in dieser Zeit? Von UFO werde ich kaum eine Antwort bekommen, der ignoriert mich, der Ignorant ;).

Tja, das hast Du Dir selbst zuzuschreiben. Vermutlich waren es dumme Kommentare zur 6400, die ich nicht mehr lesen wollte. Man begegnet sich eben immer zweimal im Leben...
</OT>

UFO · 9. Februar 2013

Zitat von S:oren

Normalerweise die Initialisierung des Tuners vor dem DRXK-Demod. Das war aber im Logfile geloescht...

Das ist der Download der Firmware. Da gab es mal ein Problem bei synchronem Laden der Firmware bei der Device-Erkennung, die ab einer Version von udev in einen Timeout laeuft. Deshalb kann der Kernel neuerdings Firmware selbst laden (und drxk laedt asynchron, was in der Kombi wenig Sinn macht)...

Der drxk-Treiber aus meinen Repositories lädt die Firmware immer synchron während der Initialisierung. Alles andere wäre falsch. Falls man Firmware laden möchte, muß dies nämlich das erste sein, was man mit dem Chip macht. Der Treiber des Kernels ist diesbzgl. broken.

Synchrones Laden führt bei gewissen udev/Kernel-Kombinationen zu Problemen. Abhilfe s.o.

CU
Oliver

UFO · 9. Februar 2013

Zitat von seahawk1986

Hallo,
könnte man evtl. diesen Patch, der die Tasten der Fernbedienung für die TT S2-6400 FF optional direkt über das Kernel Input Device auswertbar macht in das media-build-experimental aufnehmen?
[yaVDR 0.5] Neue DVB Treiber für TT S2-6400 erstellen und installieren

Ich denke, das würde den Empfänger leichter nutzbar machen, wenn man nicht über das remote-Plugin gehen will (und ein paar yaVDR-Nutzer mit dieser Karte glücklich machen).

Änderungen am TT S2-6400 Treiber sollten über das Repository von powarman gehen. In media_build_experimental möchte ich Treiber nur patchen, wenn dies unbedingt notwendig ist. Aus meiner Sicht ist der Patch ok. (Ob das Mapping stimmt, habe ich nicht kontrolliert.)

CU
Oliver

UFO · 9. Februar 2013

Vergesst, was ich oben über andere Fehlerursachen geschrieben habe!

Mit ddbridge:

Zitat von UFO

Bei mir sieht es so aus - mit ein paar zusätzlichen Ausgaben in load_microcode():

Code

Feb  9 05:06:34 darkstar kernel: [  721.269131] drxk: status = 0x639130d9
Feb  9 05:06:34 darkstar kernel: [  721.269196] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
Feb  9 05:06:34 darkstar kernel: [  721.292265] load_microcode vor request
Feb  9 05:06:34 darkstar kernel: [  721.299137] load_microcode download
Feb  9 05:06:34 darkstar kernel: [  721.668978] load_microcode release
Feb  9 05:06:34 darkstar kernel: [  721.669049] load_microcode fertig
Feb  9 05:06:34 darkstar kernel: [  721.705103] DRXK driver version 0.9.4300
Feb  9 05:06:34 darkstar kernel: [  721.711404] drxk: frontend initialized.
Feb  9 05:06:36 darkstar kernel: [  723.392432] DDBridge 0000:05:00.0: DVB: registering adapter 4 frontend 0 (DRXK DVB-C DVB-T)...


Feb  9 05:06:36 darkstar kernel: [  723.401130] drxk: status = 0x639130d9
Feb  9 05:06:36 darkstar kernel: [  723.401195] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
Feb  9 05:06:36 darkstar kernel: [  723.420242] load_microcode vor request
Feb  9 05:06:36 darkstar kernel: [  723.427095] load_microcode download
Feb  9 05:06:37 darkstar kernel: [  723.791517] load_microcode release
Feb  9 05:06:37 darkstar kernel: [  723.791588] load_microcode fertig
Feb  9 05:06:37 darkstar kernel: [  723.829049] DRXK driver version 0.9.4300
Feb  9 05:06:37 darkstar kernel: [  723.835381] drxk: frontend initialized.
Feb  9 05:06:38 darkstar kernel: [  725.516474] DDBridge 0000:05:00.0: DVB: registering adapter 5 frontend 0 (DRXK DVB-C DVB-T)...

Alles anzeigen

D.h. bei mir gibt es diese Verzögerung beim Laden der Firmware nicht. Ich werde es jedoch noch einmal mit einer ngene-Bridge kontrollieren.

Da war ich wohl etwas voreilig, mit ngene habe ich diese Verzögerungen auch:

Code

Feb  9 10:03:01 darkstar kernel: [   39.915276] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas
Feb  9 10:03:01 darkstar kernel: [   39.915373] ngene 0000:01:00.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
Feb  9 10:03:01 darkstar kernel: [   39.915444] ngene: Found Digital Devices DuoFlex PCIe or miniPCIe
Feb  9 10:03:01 darkstar kernel: [   39.916478] ngene: Device version 1
Feb  9 10:03:01 darkstar kernel: [   39.935837] ngene: Loading firmware file ngene_18.fw.
Feb  9 10:03:01 darkstar kernel: [   39.957914] No CXD2099 detected at 40
Feb  9 10:03:01 darkstar kernel: [   39.987919] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
Feb  9 10:03:01 darkstar kernel: [   40.049500] load_microcode vor request
Feb  9 10:03:01 darkstar kernel: [   40.064438] load_microcode download
Feb  9 10:03:04 darkstar kernel: [   42.846732] load_microcode release
Feb  9 10:03:04 darkstar kernel: [   42.846802] load_microcode fertig
Feb  9 10:03:04 darkstar kernel: [   42.899149] DRXK driver version 0.9.4300
Feb  9 10:03:04 darkstar kernel: [   42.950632] drxk: frontend initialized.
Feb  9 10:03:06 darkstar kernel: [   45.103053] DVB: registering new adapter (nGene)
Feb  9 10:03:06 darkstar kernel: [   45.103120] ngene 0000:01:00.0: DVB: registering adapter 2 frontend 0 (DRXK DVB-C DVB-T)...
Feb  9 10:03:06 darkstar kernel: [   45.135880] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
Feb  9 10:03:06 darkstar kernel: [   45.197530] load_microcode vor request
Feb  9 10:03:06 darkstar kernel: [   45.204539] load_microcode download
Feb  9 10:03:09 darkstar kernel: [   47.985114] load_microcode release
Feb  9 10:03:09 darkstar kernel: [   47.985185] load_microcode fertig
Feb  9 10:03:09 darkstar kernel: [   48.039186] DRXK driver version 0.9.4300
Feb  9 10:03:09 darkstar kernel: [   48.090919] drxk: frontend initialized.
Feb  9 10:03:11 darkstar kernel: [   50.243080] DVB: registering new adapter (nGene)
Feb  9 10:03:11 darkstar kernel: [   50.243146] ngene 0000:01:00.0: DVB: registering adapter 3 frontend 0 (DRXK DVB-C DVB-T)

Alles anzeigen

Vermutlich liegt es daran, daß I2C-Transfers über die ngene-Bridge langsamer ablaufen. Ich werde mich diesbzgl. erkundigen.

CU
Oliver

e9hack · 9. Februar 2013

Es gibt zwei Verzögerungen. Hier wird die Firmware geladen:

Code

9 15:08:11 vdr kernel: [ 8178.596071] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
  9 15:08:12 vdr kernel: [ 8179.005931] DRXK driver version 0.9.4300

Hier wird der Tuner-Chip initialisiert:

Code

9 15:08:12 vdr kernel: [ 8179.012464] drxk: frontend initialized.
  9 15:08:12 vdr kernel: [ 8179.012472] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1250) dvb_input_attach
     -> call to tuner_attach_tda18271()
  9 15:08:13 vdr kernel: [ 8180.423416] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1253) dvb_input_attach
  9 15:08:13 vdr kernel: [ 8180.423435] DDBridge 0000:02:00.0: DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T).

Gruß
e9hack

franzf3 · 10. Februar 2013

Hallo,
habe heute nochmal alles übersetzt (da ein neuer Kernel bei Suse gekommen ist.) Habe auch die Info's von Jasmin gelesen. Vielen Dank Jasmin. Das adapter_alloc=3
Habe ich mal auskommentiert. Den echo Befehle habe ich mit 01 02 ausgeführt. Ich hoffe das war richtig, das TAB1 ist leer.

Leider bleibt der Bildschirm dunkel, mit kaffein habe auch beide Empfänger probiert. Gibt es hier noch etwas was man probieren kann?

Franz

Hier das log:

Feb 10 22:13:03 linux-wyeu kernel: [ 142.685549] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687316] WARNING: You are using an experimental version of the media stack.
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687317] As the driver is backported to an older kernel, it doesn't offer
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687318] enough quality for its usage in production.
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687318] Use it with care.
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687319] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687319] 8b2aea7878f64814544d0527c659011949d52358 [media] em28xx: prefer bulk mode on webcams
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687320] a3efa1cc0e067675ffa2d2c357cbe1da0db4653b [media] em28xx: make the logs reflect the specific chip name
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687321] aa51496b21542855e779a78bf33384002f01acb6 [media] em28xx: display the isoc/bulk mode
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687321] experimental: 9b79c0d0acf1607158e1bdb70fe913059894bfd5 experimental: Add workaround for CAM write errors.
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687322] ngene-octopus-test: a8742d5952072f2237cdf28ae4cbb78fa6039f80 ddbridge: Add Digital Devices Cine S2 V6.5
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687323] v4l-dvb-saa716x: a605fbd008412f3a308f30b8b2f536bd2143fbcb aa716x_ff: print decimal digits for firmware version.
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687778] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687805] DDBridge driver detected: Digital Devices Octopus CI single
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687828] HW 00010006 REG 00010002
Feb 10 22:13:03 linux-wyeu kernel: [ 142.687882] DDBridge 0000:01:00.0: irq 55 for MSI/MSI-X
Feb 10 22:13:03 linux-wyeu kernel: [ 142.688554] Port 0 (TAB 1): NO MODULE
Feb 10 22:13:03 linux-wyeu kernel: [ 142.690117] Port 1 (TAB 2): DUAL DVB-C/T
Feb 10 22:13:03 linux-wyeu kernel: [ 142.690122] Port 2 (TAB 3): CI internal
Feb 10 22:13:03 linux-wyeu kernel: [ 142.690616] DVB: registering new adapter (DDBridge)
Feb 10 22:13:03 linux-wyeu kernel: [ 142.690619] DVB: registering new adapter (DDBridge)
Feb 10 22:13:03 linux-wyeu kernel: [ 142.690620] DVB: registering new adapter (DDBridge)
Feb 10 22:13:03 linux-wyeu kernel: [ 142.693343] stv0367 found
Feb 10 22:13:03 linux-wyeu kernel: [ 142.952391] tda18212dd: ChipID 4724
Feb 10 22:13:03 linux-wyeu kernel: [ 142.952822] tda18212dd: PowerState 01
Feb 10 22:13:03 linux-wyeu kernel: [ 143.087365] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
Feb 10 22:13:03 linux-wyeu kernel: [ 143.088305] stv0367 found
Feb 10 22:13:03 linux-wyeu kernel: [ 143.346716] tda18212dd: ChipID 4724
Feb 10 22:13:03 linux-wyeu kernel: [ 143.347146] tda18212dd: PowerState 00
Feb 10 22:13:03 linux-wyeu kernel: [ 143.603792] DDBridge 0000:01:00.0: DVB: registering adapter 1 frontend 0 (STV0367 DVB-C DVB-T)...
Feb 10 22:13:03 linux-wyeu kernel: [ 143.605832] redirect: 01, 02
Feb 10 22:13:08 linux-wyeu kernel: [ 148.597846] slot reset 0
Feb 10 22:13:09 linux-wyeu kernel: [ 149.473856] dvb_ca adapter 2: DVB CAM detected and initialised successfully

UFO · 10. Februar 2013

Zitat von franzf3

Das adapter_alloc=3
Habe ich mal auskommentiert.

Keine gute Idee. Teste, ob es mit adapter_alloc=3 funktioniert.

CU
Oliver

franzf3 · 11. Februar 2013

Hallo,
habe das wieder eingebaut, aber leider auch ohne Erfolg. Alles dunkel bis auf ZDF und ARD. Hier nochmal das log. Es hat sich nichts verändert. Ist den der echo Befhel korrekt ?

Gruss
Franz
ll /dev/dvb/adapter0/
insgesamt 0
crw-rw----+ 1 root video 212, 8 11. Feb 23:10 ca0
crw-rw----+ 1 root video 212, 0 11. Feb 23:10 demux0
crw-rw----+ 1 root video 212, 4 11. Feb 23:10 demux1
crw-rw----+ 1 root video 212, 1 11. Feb 23:10 dvr0
crw-rw----+ 1 root video 212, 5 11. Feb 23:10 dvr1
crw-rw----+ 1 root video 212, 3 11. Feb 23:10 frontend0
crw-rw----+ 1 root video 212, 7 11. Feb 23:10 frontend1
crw-rw----+ 1 root video 212, 2 11. Feb 23:10 net0
crw-rw----+ 1 root video 212, 6 11. Feb 23:10 net1
crw-rw----+ 1 root video 212, 9 11. Feb 23:10 sec0

# tail -f /var/log/messages
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
Feb 11 23:10:29 linux-wyeu su: (to root) tv on /dev/pts/0
Feb 11 23:10:52 linux-wyeu kernel: [ 139.087067] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088807] WARNING: You are using an experimental version of the media stack.
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088809] As the driver is backported to an older kernel, it doesn't offer
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088811] enough quality for its usage in production.
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088812] Use it with care.
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088813] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088814] 8b2aea7878f64814544d0527c659011949d52358 [media] em28xx: prefer bulk mode on webcams
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088815] a3efa1cc0e067675ffa2d2c357cbe1da0db4653b [media] em28xx: make the logs reflect the specific chip name
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088817] aa51496b21542855e779a78bf33384002f01acb6 [media] em28xx: display the isoc/bulk mode
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088818] experimental: 9b79c0d0acf1607158e1bdb70fe913059894bfd5 experimental: Add workaround for CAM write errors.
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088820] ngene-octopus-test: a8742d5952072f2237cdf28ae4cbb78fa6039f80 ddbridge: Add Digital Devices Cine S2 V6.5
Feb 11 23:10:52 linux-wyeu kernel: [ 139.088822] v4l-dvb-saa716x: a605fbd008412f3a308f30b8b2f536bd2143fbcb aa716x_ff: print decimal digits for firmware version.
Feb 11 23:10:52 linux-wyeu kernel: [ 139.089316] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
Feb 11 23:10:52 linux-wyeu kernel: [ 139.089389] DDBridge driver detected: Digital Devices Octopus CI single
Feb 11 23:10:52 linux-wyeu kernel: [ 139.089436] HW 00010006 REG 00010002
Feb 11 23:10:52 linux-wyeu kernel: [ 139.089496] DDBridge 0000:01:00.0: irq 53 for MSI/MSI-X
Feb 11 23:10:52 linux-wyeu kernel: [ 139.090150] Port 0 (TAB 1): NO MODULE
Feb 11 23:10:52 linux-wyeu kernel: [ 139.091649] Port 1 (TAB 2): DUAL DVB-C/T
Feb 11 23:10:52 linux-wyeu kernel: [ 139.091652] Port 2 (TAB 3): CI internal
Feb 11 23:10:52 linux-wyeu kernel: [ 139.092138] DVB: registering new adapter (DDBridge)
Feb 11 23:10:52 linux-wyeu kernel: [ 139.094967] stv0367 found
Feb 11 23:10:52 linux-wyeu kernel: [ 139.347717] tda18212dd: ChipID 4724
Feb 11 23:10:52 linux-wyeu kernel: [ 139.348144] tda18212dd: PowerState 01
Feb 11 23:10:52 linux-wyeu kernel: [ 139.482427] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
Feb 11 23:10:52 linux-wyeu kernel: [ 139.483267] stv0367 found
Feb 11 23:10:53 linux-wyeu kernel: [ 139.737674] tda18212dd: ChipID 4724
Feb 11 23:10:53 linux-wyeu kernel: [ 139.738090] tda18212dd: PowerState 00
Feb 11 23:10:53 linux-wyeu kernel: [ 139.994895] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
Feb 11 23:10:53 linux-wyeu kernel: [ 139.997124] redirect: 01, 02
Feb 11 23:10:58 linux-wyeu kernel: [ 144.989337] slot reset 0
Feb 11 23:10:59 linux-wyeu kernel: [ 145.865441] dvb_ca adapter 0: DVB CAM detected and initialised successfully
Feb 11 23:11:05 linux-wyeu kernel: [ 151.945913] IPv4: martian source 255.255.255.255 from 192.168.178.25, on dev eth1
Feb 11 23:11:05 linux-wyeu kernel: [ 151.945919] ll header: 00000000: ff ff ff ff ff ff 00 11 32 0c 45 68 08 00 ........2.Eh..

jasminj · 12. Februar 2013

Zitat von franzf3

Ist den der echo Befehl korrekt ?

Bei mir sieht das so aus:
Port 0 (TAB 1): DUAL DVB-S2
Port 1 (TAB 2): NO MODULE
Port 2 (TAB 3): CI
Und funktioniert mit: redirect: 00, 02
Bei dir ist es :
Port 0 (TAB 1): NO MODULE
Port 1 (TAB 2): DUAL DVB-C/T
Port 2 (TAB 3): CI internal
Guckst du hier for Details.
Der Parameter müsste also 02 02 sein, denke ich. Allerdings spricht der Artikel von der CineS2 V6.0
Hier findest du noch mehr dazu. Probiere es mal aus.

Ich sehe keine Ausgaben vom VDR. Du scheinst ein anderes Programm zu benutzen. Mit dem VDR würde man die Initialisierung am Session Layer des CAM sehen. Da kommt dann die Ausgabe, dass es sich um ein XXX Modul handelt. Du kannst aber auch mit dem dvb-core Modul Parameter cam_debug=1, das Logging des Treibers anwerfen. Allerdings ist der sehr gesprächig. Man sieht dann aber, ob das Modul erkannt wird und ob damit gesprochen wird.
Wenn du die Logs postets, dann vielleicht besser mit pastbinit.

LG
Jasmin

franzf3 · 12. Februar 2013

Ja, ich möchte den VDR installieren, keine Frage. Aber ich teste die Sache mit kaffein. Ich habe die echo 02 02 heute getested ohne Erfolg. Also mit:

KERNEL=="ddbridge0", ACTION=="add", SUBSYSTEM=="ddbridge", RUN+="/etc/udev/ddbridge_redirect '02 02'"

Mit dem gnutv -cammenu bekomme ich die Infos von der Karte. Allerdings auch: en50221_stdcam_llci_poll: Error reported by stack:-3 was auch immer das bedeutet.

Ich versuche mal am Wochenende den Text zu verstehen. Ich habe das wohl nicht korrekt verstanden.

Den Tipp mit dem pastbinit nehme ich gerne an, wusste nichts von dem Tool. Bin noch recht neu in diesen Foren.

Gruss

Franz

jasminj · 13. Februar 2013

Zitat von franzf3

Ja, ich möchte den VDR installieren, keine Frage. Aber ich teste die Sache mit kaffein. Ich habe die echo 02 02 heute getested ohne Erfolg. Also mit:
KERNEL=="ddbridge0", ACTION=="add", SUBSYSTEM=="ddbridge", RUN+="/etc/udev/ddbridge_redirect '02 02'"

Ich nehme an im Syslog war die redirect Ausgabe vom Kernel zu sehen? Der Treiber hat leider keine Rücklesemöglichkeit für diesen Parameter im SysFS. Ich wollte das nachbauen, aber dann hätte ich mir das in einer neuen Variablen merken müssen, weil der Treiber das nur einmal einstellt, soweit ich mich erinnere. War mir dann doch nicht so wichtig ... .

Zitat von franzf3

Mit dem gnutv -cammenu bekomme ich die Infos von der Karte. Allerdings auch: en50221_stdcam_llci_poll: Error reported by stack:-3 was auch immer das bedeutet.

Ich hab das mal gegoogelt und mich dann weiter gehangelt und das und das und das gefunden (musst die Funktionen/Symbole dort suchen). Das ist jetzt nur ein guess von mir, aber ich denke es ist ein Timeout.
Ich habe dir den Tipp mit dem "cam_debug=1" im letzten Post gegeben. Wenn dir der zu gesprächig ist, dann musst eben die entsprechenden Zeilen im Treiber auskommentieren. Das sind vor allem die ioctl Aufrufe. Aber man kommt auch so durch, weil man das syslog ja später genauer analysieren kann.

Zitat von franzf3

Den Tipp mit dem pastbinit nehme ich gerne an, wusste nichts von dem Tool. Bin noch recht neu in diesen Foren.

Hab ich auch erst hier, vor 2 Wochen gelernt

LG
Jasmin

mini73 · 13. Februar 2013

Zitat von jasminj

Der Treiber hat leider keine Rücklesemöglichkeit für diesen Parameter im SysFS. Ich wollte das nachbauen, aber dann hätte ich mir das in einer neuen Variablen merken müssen, weil der Treiber das nur einmal einstellt, soweit ich mich erinnere.

Falls du das doch mal machen willst, bedenke, dass sich das redirect mehrmals aufrufen lässt, weil es ja auch mehrere Tuner/CIs geben kann.

Lars

gda · 13. Februar 2013

Nochmal was ganz anderes was mir gerade einfällt. Mir ist aufgefallen, dass bei einem make -jN mit N > 1 die Patcherei kräftig auf die Nase fällt, weil dann zwei Make-Threads gleichzeitig versuchen zu patchen. Das scheint irgendwie nicht atomar gelöst zu sein. Ich weiß nicht warum das vorher nie aufgefallen ist. Vielleicht liegt es daran, dass mein Desktop ziemlich zügig zu werke geht. Aus Zeitgründen kann ich leider keine Patches für das Problem liefern.

Da mich UFO nach wie vor ignoriert mag mich vielleicht jemand quoten?

Gerald

Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Jetzt mitmachen!

Teilen

Tags

Benutzer online in diesem Thema