Bildausgabe hängt

frosch01 · 28. Oktober 2005

Hallo,

habe seit gestern die neue FW drauf. Immerhin 22Stunden ohne Probleme.

Mal sehen obs anhält... ?)

frosch01 · 6. November 2005

Ok,

es war wohl nix. Leider immer noch die selben Probleme.

Noch jemand da?

jackfritt · 7. November 2005

Also ich habe seit 25.10 keine av7110_fw_cmd error´s mehr.

Hoffe das geht so weiter.

Gruss,

Jörg

pum · 3. Dezember 2005

Gibt es inzwischen schon neuigkeiten ?

Habe exakt das gleiche Problem

Code

dvb-ttpci: load_dram(): writing DRAM block 77
dvb-ttpci: waitdebi(): dee84000
dvb-ttpci: waitdebi(): dee84000
dvb-ttpci: waitdebi(): dee84000
dvb-ttpci: av7110_bootarm(): load dpram code
dvb-ttpci: av7110_firmversion(): dee84000
dvb-ttpci: av7110_fw_request(): dee84000
dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
dvb-ttpci: av7110_fw_request error -110
dvb-ttpci: av7110_fw_query error -110
dvb-ttpci: failed to boot firmware @ card 0

Alles anzeigen

Teste derzeit mit Kernel 2.6.14.2 und cvs DVB ...
Firmware ist so ziemlich alles durchprobiert was noch zu haben ist.
VDR ist 1.3.33

Der VDR laeuft max. 2 Stunden, danach die bekannten Bild/Tonhaenger.
Ein entladen der Module und neues Laden bringt genausowenig eine Besserung, wie auch ein reboot.

Es wird erst besser wenn der Strom gezogen wird und man 5 Sekunden wartet.

Weiss jemand was :

Code

dvb-ttpci: gpioirq unknown type=0 len=0

bedeutet ?

Besten dank

Sven

jackfritt · 5. Dezember 2005

Hallo,

Zitat
Original von pum
Gibt es inzwischen schon neuigkeiten ?

Habe exakt das gleiche Problem
Code
dvb-ttpci: load_dram(): writing DRAM block 77
dvb-ttpci: waitdebi(): dee84000
dvb-ttpci: waitdebi(): dee84000
dvb-ttpci: waitdebi(): dee84000
dvb-ttpci: av7110_bootarm(): load dpram code
dvb-ttpci: av7110_firmversion(): dee84000
dvb-ttpci: av7110_fw_request(): dee84000
dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
dvb-ttpci: av7110_fw_request error -110
dvb-ttpci: av7110_fw_query error -110
dvb-ttpci: failed to boot firmware @ card 0
Alles anzeigen
Teste derzeit mit Kernel 2.6.14.2 und cvs DVB ...
Firmware ist so ziemlich alles durchprobiert was noch zu haben ist.
VDR ist 1.3.33

Der VDR laeuft max. 2 Stunden, danach die bekannten Bild/Tonhaenger.
Ein entladen der Module und neues Laden bringt genausowenig eine Besserung, wie auch ein reboot.
Es wird erst besser wenn der Strom gezogen wird und man 5 Sekunden wartet.
Alles anzeigen

Ich habe leider auch immer noch das Problem. Samstag abend passierte mir leider wieder dieser Fehler. Also weiterhin warten angesagt. Bei mir läuft der VDR allerdings viel länger bevor der Fehler auftritt. Und bei mir hilft auch ein neuladen der Treiber.

Zitat
Weiss jemand was :
Code
dvb-ttpci: gpioirq unknown type=0 len=0
bedeutet ?

Nix schlimmes einfach ignorieren. (Hat man mir damals gesagt.)

Gruss,

Jörg

mpanczyk · 16. Dezember 2005

Ok, dann will ich mich mal zu dieser Runde dazugesellen. Auch ich habe den Fehler das mein Bild nach einiger Zeit schwarz wird und erst durch Neustart von vdr und dvb Treibern wieder zum Leben erweckt werden kann. Habe es mit verschiedenen Treiberversionen, vdr Versionen und Firmware Versionen probiert, ohne Glück. Hier meine derzeitige Konfiguration

Hauppauge Nexus-S 2.1 FF Karte (2. Device)
Hauppauge Nova-T Budget Karte (Alte Version) (1. Device mit Fernbedienung)

vdr 1.3.37
Kernel 2.6.14.4
Firmware Nexus-S 261f, 262, derzeit 261d
Firmware Nova-T 2c

Installierte Plugins: femon, streamdev server, remote (jeweils neueste Version

Während die Programme der Nexus nur schwarz sind (nach 1 bis 20 Stunden) bleibt die DVB-T Karte stabil, die programme können auch nach dem Problem noch ohne Probleme angezeigt werden. Habe schon mal die Karten in unterschieldiche PCI Slots gesteckt aber alles ohne Erfolg.

Die derzeit eingesetzte 221d hat bisher noch kein problem gezeigt, ist aber auch erst seit 6 Stunden im Einsatz, schauen wir mal

Tschau
Matthias

jackfritt · 19. Dezember 2005

Ich denke du nutzt nicht die aktuelle Firmware.
Ich habe hier Version Firmware c0002622

Evtl. solltest du diese mal probieren ?

Gruss,

Jörg

mpanczyk · 19. Dezember 2005

Hi Jörg,

also die Firmware c0002622 war bei meinen Tests bisher eindeutig die schlechteste Lösung, da hatte ich auch Abstürze im Treiber. Mit der 221d läuft es derzeit recht stabil, hatte in 2 Tagen jetzt nur einen Hänger. Ich werde aber sicherlich weiter testen.

Danke erst mal für Deine Antwort

Matthias

SurfaceCleanerZ · 19. Dezember 2005

Wie wärte es mit der ct VDR4 fw? Die ist irgendwie modifiziert...

mpanczyk · 19. Dezember 2005

Hättest Du da mal einen Link im Angebot. Schaden kanns ja nicht das mal zu testen. Aber wie gesagt seit 2 Tagen ist das derzeit mit 221d stabil (und bleibt es hoffentlich).

Danke
Matthias

Nachtrag: Danke an Dr Seltsam: 221d => 261d (Das war keine spezielle Version sondern Tippfehler)

Dr. Seltsam · 19. Dezember 2005

Zitat

Original von mpanczyk
Hättest Du da mal einen Link im Angebot. Schaden kanns ja nicht das mal zu testen. Aber wie gesagt seit 2 Tagen ist das derzeit mit 221d stabil (und bleibt es hoffentlich).

Danke
Matthias

was ist 221d? Ich kenne nur 261d, 261f.
Aktuell ist Testversion 0x2623 mit Testnummer 0xFF:
http://www.suse.de/~werner/test_av-1.29.tar.bz2

mpanczyk · 19. Dezember 2005

OK, gute Frage, 221d ist ein Tippfehler, ist natürlich 261d.

Korrigiere ich dann direkt mal direkt in meinem Originalposting bevor da noch jemand wirklich so was sucht.

Danke für den Link, die Version werde ich dann mal installieren und testen.

Danke
Matthias

SurfaceCleanerZ · 19. Dezember 2005

Gibt es m. Wissens nach nicht im Netz, könnte sie aber heut abend mailen!

Ich vermute aber eher dass es wie weiter oben besprochen am schlechten Treiber von linuxtv liegt. Der bei c't VDR2 eingesetzte lief rockstable im Ggs. zum bei c't VDR4 eingesetztem!

Warum muss man auch alle Karten mit 1 Treiber unterstützen? Ein Treiber für alle Technotrend und Baugleiche und einen (oder mehrere) (Ramsch)treiber für den Rest!

frosch01 · 20. Dezember 2005

Hi,

bin auch mal wieder da. Habe leider noch nichts zu unseren Problemen herausgefunden

Seit gestern habe ich noch eine neue Karte drin. Da ist mir folgendes aufgefallen:

Wenn ich im Femon-Plugin durch die Taste <- die Karte wechsle hängt die Bidlausgabe der Premium-Karte. Die Budget-Karte zeigt dieses Problem nicht.

Hierbei geht die Übertragungsrate für Bild und Ton auf 0 Die Ausgabe für das Format (4:3) und ein P (PAL?) sind mal da und mal nicht. Der Rest ist wie gehabt.

Im Vergleich zu echten Hängern genügt hier ein Wechsel des Proramms um wieder ein Bild zu bekommen.

Was auch immer dies heißen mag, vielleicht hat es auch etwas mit dem echten Hänger zu tun.

Wenns bei mir mal wieder hängt werde ich auch dies prüfen. Vielleicht eignet sich diese Info als Input für einige Treiber / Firmwareentwickler.

Gruss

frosch01

LordZodiac · 20. Dezember 2005

Hallo frosch01,

das Femon-Plugin hat Probleme beim wechseln von der Budgetkarte zum Primärdevice. Dort ist immer das Bild/Ton weg. Nach dem umschalten läuft sie wieder normal.

bis dann LordZodiac

mpanczyk · 21. Dezember 2005

OK, dann auch mal ein Zwischenbericht von mir. Mit Firmware 261d läuft meine FF Karte jetzt seit Sonntag ohne jeglichen Hänger, sieht alles sehr solide aus. Somit bleib ich dann erst mal dabei.

Matthias

jackfritt · 21. Dezember 2005

Hallo frosch01,

ich finde es toll das du so unermüdlich versuchst den Fehler einzugrenzen.

Aber ich kann dir nur sagen das dies schon viele versucht haben und alle haben bisher aufgegeben. Es lässt sich keine Gemeinsamkeit finden um den Fehler genauer einzugrenzen. Er tritt zwar bei sehr vielen Leuten auf aber leider immer nur sporadisch und Zusammenhanglos.

Lass dich bitte nicht davon beirren. Aber ich kann dir gerne diverse links in dem Board nennen wo dieses Problem diskutiert wird. Ich glaube ich kann sagen ich habe alle ausprobiert. Leider bisher immer ohne Erfolg. Spätestens nach 3 Monaten war der Fehler wieder da. Mir kommt es so vor als läge es am Wetter.

Ich glaube für meinen Teil das es was mit dem Signal zu tun hat. Mann kann den Fehler nämlich öfter produzieren wenn man einfach mal kein Satellitenkabel an den vdr anschliesst. Irgendwann bei einer Aufnahme hängt er dann. Aber ich kann nicht sagen ob das auch wirklich genau dieses Problem betrifft.

Also lass dich nicht von Leuten wie mir einschüchtern Weitersuchen !
Evtl. findest du ja den "heiligen Bug".

Soviel zum Wort zum Dienstag.

Gruss,

Jörg

frosch01 · 3. Januar 2006

Hallo,

ich werde trotzdem erst mal dran bleiben, zumal main System jetzt seit Mitte Dezember ohne einen Ansturz stabil ist Was hat sich getan?

1. Habe eine 2. Karte (Budget) eingebaut.
2. Habe einen zusätzlichen Lüfter eingebaut (CPU-Temperatur ist jetzt 10K kleiner).
3. Ferrit-Kerne an beiden SAT-Kabeln
4. Habe KDE (KVDR) und auch X aktualisiert.

Seitdem ich die Karte tatsächlich verwende (Kernel mit Treiber für Karte und SAT-Kabel gelegt) hatte ich keine Probleme mehr. Der blose Einbau der Karte hatte nichts geändert. Dies war nämlich mein letzter Absturz. Der Lüfter war zu diesem Zeitpunkt bereits drin!

Erinnere mich hierzu auch an eine Aussage in einem Posting, wonach Systeme mit 2 Karten stabiler laufen. Wer es war weiss ich nicht mehr, ich glaube jedoch es war in diesem Thread. Habe jetzt jedoch schon 15 Minuten gesucht und finde den Beitrag nicht. In jedem Fall hatte der Absender bereits mehrere System aufgebaut und ist immer wieder auf das Problem getroffen. Die stabilsten Systeme waren die mit mehreren Karten. War irgendein Profi (LordZodiac oder so)

Das neue KVDR geht bei mir übrigens jetzt nicht mehr über Overlay sondern nur noch mit XV. Musste eine entsprechende Kommandozeilenoption geben. Vielliecht hängt die Besserung auch damit zusammen.

frosch01

SurfaceCleanerZ · 3. Januar 2006

Meins läuft auch stabil und ist durch die neueste Firmware auch schneller geworden!
Hab es mittlerweile auf beiden Geräten!

Gibt es ein Temperaturüberwachungsplugin?

Der_Pit · 3. Januar 2006

Hi,

ich hab mein System zu Weihnachten aktualisiert, von einem MT-gepanschten 1.3.2? auf die Cody-Version 1.3.37, und auch die Firmware auf 2623 gebracht. Mit dem alten System hatte ich öfter beim Zappen die ARM-crashes, das hatte nach dem upgrade aufgehört
Jetzt habe ich am Wochenende eine weitere Karte eingebaut (PVR 150MCE für analog TV), und seitdem gibt's wieder Probleme: Manchmal (bislang 3-4 Mal) habe ich beim zurückschalten von einem analogen auf einen DVB-S Kanal ein schwarzes Bild. Suche im Logfile bringt folgendes:

Code

Jan  2 21:18:52 vdr  vdr[5244]: switching to channel 104
Jan  2 21:18:52 vdr  vdr[5588]: ERROR: attempt to use cPlayer::PlayPes() without attaching to a cDevice!
Jan  2 21:18:52 vdr  vdr[5588]: transfer thread ended (pid=5588, tid=65546)
Jan  2 21:18:52 vdr  vdr[5589]: receiver on device 5 thread ended (pid=5589, tid=66571)
Jan  2 21:18:52 vdr  vdr[5244]: buffer stats: 1083256 (51%) used
Jan  2 21:18:53 vdr  vdr[5244]: ERROR: can't open XPM file '/etc/vdr/plugins/skinelchi/logos/rtl 5.xpm'
Jan  2 21:18:53 vdr  vdr[5590]: transfer thread started (pid=5590, tid=67594)
Jan  2 21:18:53 vdr  vdr[5591]: receiver on device 5 thread started (pid=5591, tid=68619)
Jan  2 21:18:54 vdr  vdr[5590]: clearing device because of consecutive poll timeouts
Jan  2 21:18:55 vdr  vdr[5591]: buffer usage: 70% (tid=67594)
Jan  2 21:18:55 vdr  vdr[5591]: buffer usage: 80% (tid=67594)
Jan  2 21:18:55 vdr  vdr[5591]: buffer usage: 90% (tid=67594)
Jan  2 21:18:55 vdr  vdr[5590]: ERROR (dvbdevice.c,1030): Connection timed out
Jan  2 21:18:55 vdr  kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  2 21:18:55 vdr  kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Jan  2 21:18:55 vdr  kernel: dvb-ttpci: av7110_fw_cmd error -110
Jan  2 21:18:56 vdr  vdr[5591]: buffer usage: 100% (tid=67594)
Jan  2 21:18:56 vdr  vdr[5591]: ERROR: 1 ring buffer overflow (177 bytes dropped)

Alles anzeigen

Ich kann weiterhin problemlos Analoge Kanäle ansehen, im Logfile sammeln sich aber die buffer usage overruns und __av7110_send_fw_cmd() Fehler. Wenn ich dann auf DVB zurückschalten will kommt

Code

Jan  2 21:29:25 vdr  vdr[5244]: switching to channel 1
Jan  2 21:29:25 vdr  vdr[5625]: ERROR: attempt to use cPlayer::PlayPes() without attaching to a cDevice!
Jan  2 21:29:25 vdr  vdr[5625]: transfer thread ended (pid=5625, tid=102410)
Jan  2 21:29:25 vdr  vdr[5626]: receiver on device 5 thread ended (pid=5626, tid=103435)
Jan  2 21:29:25 vdr  vdr[5244]: buffer stats: 1171616 (55%) used
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0007  ret 0  resp 0007 ffff  pid 203
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0006  ret 0  resp 0006 ffff  pid 16
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0005  ret 0  resp 0005 ffff  pid 17
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0004  ret 0  resp 0004 ffff  pid 0
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0003  ret 0  resp 0003 ffff  pid 20
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0000  ret 0  resp 0000 ffff  pid 18
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0001  ret 0  resp 0001 ffff  pid 18
Jan  2 21:29:25 vdr  kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0002  ret 0  resp 0002 ffff  pid 18

Alles anzeigen

und der Schirm bleibt schwarz.

Pit

Bildausgabe hängt

Jetzt mitmachen!

Teilen