__av7110_send_fw_cmd(): timeout waiting for COMMAND idle

Deejenda · 29. Dezember 2004

Danke Xyphro

Aber ich benutze Linvdr.

Da is nix mit apt-get und per debtool kann ich das paket nicht finden.

Schade

Gruß Deejenda

neumann2k · 29. Dezember 2004

Zitat

Original von wirbel
neumann2k:

Dein patch macht

Code

void cTransfer::Activate(bool On)
{
  if (On) {
     if (!active) 
       dsyslog("DEBUG:cleaning all buffers and the card");
       DeviceClear();
       ringBuffer->Clear();
       remux->Clear();
       Start();
   else if (active) {

Sollte es nicht eher ein

Code

void cTransfer::Activate(bool On)
{
  if (On) {
     if (!active) {
       dsyslog("DEBUG:cleaning all buffers and the card");
       DeviceClear();
       ringBuffer->Clear();
       remux->Clear();
       Start();
       }
   else if (active) {

Alles anzeigen

sein?

Alles anzeigen

Hallo wirbel,

das sollte egal sein, das es meiner Meinung nach nur der "Coding-Style" ist. Ich habe mal gelesen, dass man im Kernel z.B. deinen Style nicht machen darf.

Wichtig sind nur DeviceClear und die Buffers, die geleert werden.

neumann2k · 29. Dezember 2004

Zitat
Original von Xyphro
Update: Habs mit beiden Varianten probiert- mit und ohne Klammerung der if (!active)-Abfrage....

Beide male kommt sowas:
Code
Dec 29 00:10:49 vdr vdr[1177]: cTS2PES got 2 TS errors, 1 TS continuity errors
Dec 29 00:10:49 vdr vdr[1177]: cTS2PES got 3 TS errors, 1 TS continuity errors
Dec 29 00:10:49 vdr vdr[1177]: buffer stats: 118628 (5%) used
Dec 29 00:10:49 vdr vdr[1177]: max. latency time 4 seconds
Dec 29 00:10:50 vdr vdr[1177]: switching to channel 24
Dec 29 00:10:51 vdr kernel: __av7110_send_fw_cmd: timeout waiting for COMMAND idle
Dec 29 00:10:51 vdr kernel: av7110_send_fw_cmd error
Dec 29 00:10:51 vdr kernel: av7110_fw_cmd error
Dec 29 00:10:52 vdr kernel: __av7110_send_fw_cmd: timeout waiting for COMMAND idle
Dec 29 00:10:52 vdr kernel: av7110_send_fw_cmd error
Ich bin mittlerweile echt frustriert

Es verhält sich aber anders als sonst... Jetzt klappt fast alles einwandfrei, nur das OSD "stürzt ab". Dort wo sonst OSD-Einblendungen sind habe ich jetzt plötzlich bunte horizontale Streifen die ständig ihre Farben ändern...
Alles anzeigen

Wenn das OSD abstürzt, ist das ein anderer Bug. Es gab von Oliver dazu einen Patch für den DVB-Treiber. Schau doch mal bitte in die VDR-NEWS. Dort ist der Thread dazu. In deinen Logs sollte kurz nach timeout waiting for COMMAND idle auch ein BlitBitmap Fehler zu sehen sein. Wenn das so ist, hilft der Patch von Oliver weiter.

Xyphro · 29. Dezember 2004

Hmm, ist es nicht von der Funktion her schon was völlig anderes?

Code

if (!active)
   dsyslog("DEBUG:cleaning all buffers and the card");
   DeviceClear();
   ringBuffer->Clear();
   remux->Clear();
   Start();

führt DeviceClear, ... unabhängig von active immer aus, während hier:

Code

if (!active) {
       dsyslog("DEBUG:cleaning all buffers and the card");
       DeviceClear();
       ringBuffer->Clear();
       remux->Clear();
       Start();
       }

DeviceClear, etc... abhängig von active ausgeführt wird.

Leider weiss ich aber nicht, wodurch active gesetzt wird und ob es überhaupt eine Relevanz hat.

neumann2k · 29. Dezember 2004

Zitat
Original von Xyphro
Hmm, ist es nicht von der Funktion her schon was völlig anderes?
Code
if (!active)
   dsyslog("DEBUG:cleaning all buffers and the card");
   DeviceClear();
   ringBuffer->Clear();
   remux->Clear();
   Start();
führt DeviceClear, ... unabhängig von active immer aus, während hier:
Code
if (!active) {
       dsyslog("DEBUG:cleaning all buffers and the card");
       DeviceClear();
       ringBuffer->Clear();
       remux->Clear();
       Start();
       }
DeviceClear, etc... abhängig von active ausgeführt wird.

Leider weiss ich aber nicht, wodurch active gesetzt wird und ob es überhaupt eine Relevanz hat.
Alles anzeigen

Wie gesagt, ich bin kein Programmierer, aber ich glaube, das die if Abfrage unabhängig von den { sind. Man kann es so oder so machen denke ich.

LordZodiac · 29. Dezember 2004

Hallo,

neumann2k

die "{ }" sind schon wichtig.

Xyphro

Das "active" wird in cTranfer::Action() gesetzt.
Über dieses Flag wird bestimmt ob der Thread läuft.

Bei den Änderungen sollte nur DeviceClear() Auswirkung haben da beim starten des cTransfer remux und ringBuffer eh leer sind.

bis dann LordZodiac

Herthaner · 29. Dezember 2004

Ich erhalte diese Fehlermeldung auch gelegentlich, wenn ich auf einen instabilen Kanal umschalte (ich sollte meine Astra-Schüssel mal sauber ausrichten), d.h. wenn ich von Hotbirs auf beispielsweise ZDF (Astra) umschalte, dann gleich weiterzappe (weil ich ja weiss, das bei ZDF ohnehin keijhn Bild kommt), dann erhalte ich ganau dieselben Fehlermeldungen.
Auch wenn ich zwischen verschlüsselten und unverschlüsselten Sendern hin und herschalte passiert das gelegentlich.

Ich habe allerdings nur 1 Hauppauge Nexus-S mit CI verbaut.
Im CI steckt ein Dragon-CAM mit einer originalen Premiere-Karte (Kabel, habe noch nicht umschalten lassen).

UFO · 5. Januar 2005

Zitat

Original von neumann2k
so, nachdem ich mich ein wenig mit dem Problem beschäftigt habe, habe ich vielleicht eine Lösung.

Ich habe festgestellt, dass der ARM crashed, nachdem der Transfer Thread beendet wurde.

Da ich kein Programmierer bin habe ich mir ein bißchen den Source Code angeschaut, und zwei Änderungen gemacht.

Die Änderungen sind eigentlich trivial. Bevor ein Transfer Thread gestartet oder gestoppt wird, wird die Karte per DeviceClear(); "gereinigt".

Seitdem habe ich den Fehler nicht mehr. Mag aber auch Zufall sein, längere Tests werden es erst zeigen.

Vielleicht kann Oliver was dazu sagen, was er meint.

Anbei der Patch.

Alles anzeigen

Da wir den Decoder der FF-Karte wohl nicht fixen können, was die Empfindlichkeit gegenüber kaputten Daten im Transfermode angeht, scheint mir das grundsätzlich ein vielversprechender Ansatz zu sein.

Ich bezweifle allerdings, daß alle Aufrufe wirklich notwendig sind.
Außerdem ist, wie wirbel schon geschrieben hat, die Klammerung nicht korrekt. Dadurch werden einige Kommandos immer ausgeführt.

Hast Du schon versucht, den Patch zu optimieren?
- Sind die Aufrufe beim Stoppen des Transfer-Modes überhaupt nötig?
- Werden alle Aufrufe beim Starten des Transfer-Modes benötigt?

Kannst ja mal Klaus anmailen, was er dazu meint.

CU
Oliver

neumann2k · 5. Januar 2005

Zitat

Original von UFO

Da wir den Decoder der FF-Karte wohl nicht fixen können, was die Empfindlichkeit gegenüber kaputten Daten im Transfermode angeht, scheint mir das grundsätzlich ein vielversprechender Ansatz zu sein.

Ich bezweifle allerdings, daß alle Aufrufe wirklich notwendig sind.
Außerdem ist, wie wirbel schon geschrieben hat, die Klammerung nicht korrekt. Dadurch werden einige Kommandos immer ausgeführt.

Hast Du schon versucht, den Patch zu optimieren?
- Sind die Aufrufe beim Stoppen des Transfer-Modes überhaupt nötig?
- Werden alle Aufrufe beim Starten des Transfer-Modes benötigt?

Kannst ja mal Klaus anmailen, was er dazu meint.

CU
Oliver

Alles anzeigen

Halllo,

wie schon festgestellt wurde, ist das leeren der Buffer hier wirklich unnötig, da diese ja beim starten des transfer threads schoin leer sind. Wahrscheinlich sollte das DeviceClear() wirklich reichen.

Ich packe gleich mal einen angepassten Patch an. Klaus hab ich schon eine Mail geschrieben, blieb allerdings bisher unbeantwortet.

pingpong · 5. Januar 2005

Der besagte Fehler tritt bei mir auch auf, habe selbst zwei FF-DVB-C Karten, allerdings ist mir aufgefallen das es jedenfalls bei mir sehr stark von externen einstrahlungen abhängt.

Soll heißen, ich verwende beim Bau meines VDR zur Firmwareentwicklung der extensionsboards ein Atmel-Entwicklungsboard auf dem ein 16 MHz Quarz sitzt, dieses befindet sich derzeit ca. 10 - 15 cm von den Karten entfernt wenn der Fehler auftritt und ich das Entwicklungsboard abschalte ist auch das __av7110_send_fw_cmd(): timeout waiting for COMMAND idle wieder weg.

Den Patch hab ich allerdings noch nicht ausprobiert, weiß nicht ob euch das in irgendeinerweise hilft, das ist jedenfalls meine Erfahrung mit dem Problem.

Grüße,

Alwin

LordZodiac · 5. Januar 2005

Hallo neumann2k und UFO,

man sollte dann die Puffer aber im cDvbDevice::SetPlayMode(...) löschen oder noch besser währe es dann wohl im Treiber selber wenn die "Source" gewechselt wird. Da ich hier das Problem nicht habe kann ich es schlecht testen.

bis dann LordZodiac

neumann2k · 5. Januar 2005

Zitat

Original von LordZodiac
Hallo neumann2k und UFO,

man sollte dann die Puffer aber im cDvbDevice::SetPlayMode(...) löschen oder noch besser währe es dann wohl im Treiber selber wenn die "Source" gewechselt wird. Da ich hier das Problem nicht habe kann ich es schlecht testen.

bis dann LordZodiac

Hi,

kannst du mir einen Patch für den Treiber geben? Teste dann gerne. Bin aber wie gesagt leider kein Programmierer.

LordZodiac · 5. Januar 2005

Hallo neumann2k,

für den Treiber kann ich dir kein Patch geben. Hab mich mit Treiberprogrammierung noch nicht so sehr viel beschäftigt.

Ich könnte dir aber einen Patch für den Vdr machen. Dann könnste du mal testen ob es in die richtige Richtung geht?

bis dann LordZodiac

neumann2k · 5. Januar 2005

Zitat

Original von LordZodiac
Hallo neumann2k,

für den Treiber kann ich dir kein Patch geben. Hab mich mit Treiberprogrammierung noch nicht so sehr viel beschäftigt.

Ich könnte dir aber einen Patch für den Vdr machen. Dann könnste du mal testen ob es in die richtige Richtung geht?

bis dann LordZodiac

Alles anzeigen

Jo, das wäre klasse. Immer her damit

marcmerz · 5. Januar 2005

LordZodiac
Da ich das gleiche Problem habe, würde ich den Patch auch gerne testen. Config -> Sig

Gruß,
Marcus

neumann2k · 5. Januar 2005

So,

habe den Patch von LordZodiac mal eingespielt. Sieht bisher sehr gut aus.

Leider macht DVB-T momentan mit dem VDR überhaupt keinen Spaß. Die Karten brauchen irrsinnig lange zum locken. Mit den alten HEAD Treibern (2.4) war das locken viel viel schneller.

Irgendwo muß doch da der Hund begraben sein. Ich denke, es liegt _NICHT_ am frontend treiber, da ich zwei verschiedene T Karten habe (Hauppauge NOVA-t und neue Nova-t). Also die beiden haben ja verschiedene Frontends. Deshalb denke ich, liegt der Fehler irgendwo in dvb_frontend.c

Oh mann, was würde ich für eine Lösung geben...

neumann2k · 5. Januar 2005

Tja, leider zu früh gefreut:

Code

Jan  5 18:56:01 vdr vdr[3919]: playing '/video0/Old_School_(Old_School)/2005-01-04.15:05.50.99.rec/001.vdr'
Jan  5 18:56:03 vdr vdr[11095]: dvbplayer thread started (pid=11095, tid=66571)
Jan  5 18:56:03 vdr vdr[11096]: non blocking file reader thread started (pid=11096, tid=67596)
Jan  5 18:56:30 vdr vdr[11095]: SetBrokenLink: no GOP header found in video packet
Jan  5 18:56:50 vdr vdr[11095]: playing '/video0/Old_School_(Old_School)/2005-01-04.15:05.50.99.rec/002.vdr'
Jan  5 18:57:17 vdr vdr[11096]: non blocking file reader thread ended (pid=11096, tid=67596)
Jan  5 18:57:17 vdr vdr[11095]: dvbplayer thread ended (pid=11095, tid=66571)
Jan  5 18:57:17 vdr vdr[3919]: switching to channel 7
Jan  5 18:57:17 vdr vdr[11451]: transfer thread started (pid=11451, tid=68619)
Jan  5 18:57:17 vdr vdr[11452]: receiver on device 3 thread started (pid=11452, tid=69644)
Jan  5 18:57:17 vdr vdr[11453]: TS buffer on device 3 thread started (pid=11453, tid=70670)
Jan  5 18:57:24 vdr vdr[3919]: executing command 'tail -n20 /var/log/messages'
Jan  5 18:57:29 vdr vdr[3919]: switching to channel 8
Jan  5 18:57:29 vdr vdr[11451]: transfer thread ended (pid=11451, tid=68619)
Jan  5 18:57:29 vdr vdr[11453]: TS buffer on device 3 thread ended (pid=11453, tid=70670)
Jan  5 18:57:29 vdr vdr[11452]: buffer stats: 47752 (2%) used
Jan  5 18:57:29 vdr vdr[11452]: receiver on device 3 thread ended (pid=11452, tid=69644)
Jan  5 18:57:29 vdr vdr[3919]: buffer stats: 311328 (14%) used
Jan  5 18:57:31 vdr vdr[11536]: transfer thread started (pid=11536, tid=71691)
Jan  5 18:57:31 vdr vdr[11537]: receiver on device 3 thread started (pid=11537, tid=72716)
Jan  5 18:57:31 vdr vdr[11538]: TS buffer on device 3 thread started (pid=11538, tid=73742)
Jan  5 18:57:32 vdr vdr[3935]: channel 9 (Super RTL) event 18:50 'Disneys große Pause' status 4
Jan  5 18:57:38 vdr vdr[3919]: executing command 'tail -n20 /var/log/messages'
Jan  5 18:57:46 vdr vdr[3919]: switching to channel 1
Jan  5 18:57:46 vdr vdr[11536]: transfer thread ended (pid=11536, tid=71691)
Jan  5 18:57:47 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:47 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:47 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:57:48 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:48 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:48 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:57:49 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:49 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:49 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:57:50 vdr vdr[11538]: TS buffer on device 3 thread ended (pid=11538, tid=73742)
Jan  5 18:57:50 vdr vdr[11537]: buffer stats: 56776 (2%) used
Jan  5 18:57:50 vdr vdr[11537]: receiver on device 3 thread ended (pid=11537, tid=72716)
Jan  5 18:57:50 vdr vdr[3919]: buffer stats: 57152 (2%) used
Jan  5 18:57:52 vdr vdr[11649]: transfer thread started (pid=11649, tid=74763)
Jan  5 18:57:52 vdr vdr[11650]: receiver on device 3 thread started (pid=11650, tid=75788)
Jan  5 18:57:52 vdr vdr[11651]: TS buffer on device 3 thread started (pid=11651, tid=76814)
Jan  5 18:57:52 vdr vdr[3919]: max. latency time 6 seconds
Jan  5 18:57:53 vdr vdr[3935]: channel 3 (WDR Dortmund) event 18:50 'Aktuelle Stunde' status 4
Jan  5 18:57:53 vdr vdr[3935]: channel 18 (WDR Düsseldorf) event 18:50 'Aktuelle Stunde' status 4
Jan  5 18:57:53 vdr vdr[3935]: channel 19 (WDR Essen) event 18:50 'Aktuelle Stunde' status 4
Jan  5 18:57:53 vdr vdr[3935]: channel 1 (Das Erste) event 18:50 'St. Angela' status 4
Jan  5 18:57:54 vdr vdr[11649]: clearing device because of consecutive poll timeouts
Jan  5 18:57:54 vdr vdr[11649]: clearing device because of consecutive poll timeouts
Jan  5 18:57:55 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:55 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:55 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:57:56 vdr vdr[11649]: clearing device because of consecutive poll timeouts
Jan  5 18:57:57 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:57 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:57 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:57:58 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:58 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:58 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:57:59 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:57:59 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:57:59 vdr kernel: dvb-ttpci: av7110_fw_cmd error
Jan  5 18:58:00 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Jan  5 18:58:00 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error
Jan  5 18:58:00 vdr kernel: dvb-ttpci: av7110_fw_cmd error

Alles anzeigen

Verdammt! Diese Seuche muß doch lösbar sein!!!

Ich setze jetzt Kopfgeld auf dieses Problem aus:

Wer es löst, bekommt 100 €. KEIN Witz !

hotzenplotz5 · 5. Januar 2005

Zitat

Wer es löst, bekommt 100 €. KEIN Witz !

lad mal vdr ohne osdteletext

neumann2k · 5. Januar 2005

Zitat

Original von hotzenplotz5

lad mal vdr ohne osdteletext

Na, so schlau war ich auch schon. Bich auch kein Noob. Jetzt gehts ans Eingemachte

Das mit den 100 € ist wirklich kein Witz.

hotzenplotz5 · 5. Januar 2005

haette ja sein koennen ...
bei mir hat das plugin in verbindung mit dvb-t probleme gemacht warum auch immer

__av7110_send_fw_cmd(): timeout waiting for COMMAND idle

Jetzt mitmachen!

Teilen