__av7110_send_fw_cmd(): timeout waiting for COMMAND idle

Hola,

habe die gleichen Probleme mit LinVDR 0.7 - allerdings auch noch ne Menge mehr Aerger: Wenn die Kiste überhaupt mal was auf dem Bldschirm anzeigt, dann bekomme ich mittlerweile nach einigen Sekunden folgende Fehler beim Kanalumschalten im Log:

Dec 28 14:51:54 linvdr user.err kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Dec 28 14:51:54 linvdr user.warn kernel: dvb-ttpci: av7110_fw_request error
Dec 28 14:51:54 linvdr user.warn kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0005  ret ffffffff  resp 0246 0000  pid 17
Dec 28 14:51:55 linvdr user.err kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Dec 28 14:51:55 linvdr user.warn kernel: dvb-ttpci: av7110_fw_request error
Dec 28 14:51:55 linvdr user.warn kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0004  ret ffffffff  resp 3000 0000  pid 0
Dec 28 14:51:56 linvdr user.err kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Dec 28 14:51:56 linvdr user.warn kernel: dvb-ttpci: av7110_fw_request error
Dec 28 14:51:56 linvdr user.warn kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0003  ret ffffffff  resp 3000 0000  pid 20

Fehler passierem im Moment bei einer TT 1.5

cu,
Alex

sollte man den patch nicht eher mal klaus schmiedinger zukommen lassen ?
betrifft ja glaube ich doch eher vdr als den treiber ?
scheinbar leiden ja doch mehr an der fehlermeldung ?

Jaja, leider ist das Thema durch, das femon-plugin brachte die Lösung: Eine Sendung aufgezeichnet und mit dem femon gezappt, auf dem zweiten Tuner (NOVA-s) keine Signalrate mehr, d.h. Tuner Schrott - mal gucken was die Garantie sagt...

Trotzdem danke und guten Rutsch

oli

PS:welches Log hätte es denn gebraucht?

neumann2k:

Hab für mein LinVDR noch keine Entwicklungsumgebung installiert, zudem habe ich mit meiner Kombination Board/DVB multiple andere Probleme (Klötzchen bei der Wiedergabe), so dass ich erstmal was anderes zu tun hab.

Aber danke für die Info.

Alex

Habe hier ähnliche Probleme mit meinen beiden DVB-s Karten. Beim Zappen bekommt das Bild Artefakte um dann schließlich ganz stehen zu bleiben (auch beim Weiterzappen), während der Ton weiterläuft. Wenn ich VDR schnell per OSD restarte, kann ich anschließend ohne Probleme weitergucken.

Ich bilde mir ein, dass es relativ häufig passiert, wenn ich etwas zuvor Aufgenommenes sehe und im Hintergrund eine neue Aufnahme stattfindet. Beende ich dann die Wiedergabe und zappe herum, tritt das Problem gehäuft auf. Beim morgendlichen EPG-Scan (Script zappt per svdrpsend.pl alle 10s einen Kanal weiter) ist bisher aber noch nix passiert.

/var/log/messages

Dec 28 17:17:36 localhost vdr[2585]: switching to channel 15
Dec 28 17:17:37 localhost kernel: av7110_send_fw_cmd error
Dec 28 17:17:37 localhost kernel: av7110_fw_cmd error
Dec 28 17:17:38 localhost kernel: av7110_send_fw_cmd error
Dec 28 17:17:38 localhost kernel: av7110_fw_cmd error
Dec 28 17:17:39 localhost kernel: av7110_send_fw_cmd error
Dec 28 17:17:39 localhost kernel: av7110_fw_cmd error
Dec 28 17:17:39 localhost vdr[2585]: switching to channel 14
Dec 28 17:17:39 localhost vdr[2585]: switching to channel 13
Dec 28 17:17:39 localhost vdr[2585]: switching to channel 12
Dec 28 17:17:46 localhost vdr[2585]: confirm: Wirklich neu starten?
Dec 28 17:17:47 localhost vdr[2585]: confirmed

/var/log/syslog:

Dec 28 17:17:36 localhost vdr[2585]: switching to channel 15
Dec 28 17:17:37 localhost kernel: __av7110_send_fw_cmd: timeout waiting for COMMAND idle
Dec 28 17:17:37 localhost kernel: av7110_send_fw_cmd error
Dec 28 17:17:37 localhost kernel: av7110_fw_cmd error
Dec 28 17:17:38 localhost kernel: __av7110_send_fw_cmd: timeout waiting for COMMAND idle
Dec 28 17:17:38 localhost kernel: av7110_send_fw_cmd error
Dec 28 17:17:38 localhost kernel: av7110_fw_cmd error
Dec 28 17:17:39 localhost kernel: __av7110_send_fw_cmd: timeout waiting for COMMAND idle
Dec 28 17:17:39 localhost kernel: av7110_send_fw_cmd error
Dec 28 17:17:39 localhost kernel: av7110_fw_cmd error
Dec 28 17:17:39 localhost vdr[2585]: switching to channel 14
Dec 28 17:17:39 localhost vdr[2585]: switching to channel 13
Dec 28 17:17:39 localhost vdr[2585]: switching to channel 12
Dec 28 17:17:39 localhost vdr[2625]: Text2Skin: Channel display update thread ended (pid=2625, tid=311305)
Dec 28 17:17:39 localhost vdr[2626]: Text2Skin: Menu display update thread started (pid=2626, tid=327689)
Dec 28 17:17:40 localhost vdr[2626]: Text2Skin: Menu display update thread ended (pid=2626, tid=327689)
Dec 28 17:17:42 localhost vdr[2627]: Text2Skin: Menu display update thread started (pid=2627, tid=344073)
Dec 28 17:17:46 localhost vdr[2585]: confirm: Wirklich neu starten?
Dec 28 17:17:47 localhost vdr[2585]: confirmed
Dec 28 17:17:47 localhost vdr[2585]: initiating emergency exit
Dec 28 17:17:47 localhost vdr[2627]: Text2Skin: Menu display update thread ended (pid=2627, tid=344073)
Dec 28 17:17:47 localhost vdr[2585]: emergency exit requested - shutting down

nur zur info: bei mir tritt das problem auch auf. auf dem tv ist kein bild und kein ton. beim neustart des programmes "vdr" bekomm ich wieder bild, aber kein ton. starte ich den rechner "vdr" neu, dann geht wieder alles... hab mich noch nciht weiter drum gekümmert, nur eben mal fix nach der fehlermeldung gesucht und dann den thread hier gefunden.

das problem tritt bisweilen nur ein, wenn ich den rechner lange laufen lasse (> 5 h). beim "normalen" fernsehen (<3 stunden) ist mir das ganze noch nciht passiert.

wie gesagt nur zur info, dass ihr nciht allein seid mit dem problem.

gruß micrix

So, mal eben gerade den Patch eingespielt ... beim wilden Zappen crasht das Mistding immer noch.

Ich kann mich hier auch nur anschliessen. Habe ne Siemens FF DVB-C und eine Airstar2 DVB-T.
Solange keine Aufnahme von der DVB-T gestartet wird und ich NUR, wirklich NUR die DVB-C nutze, dann läuft alles einwandfrei.

Andersrum:
Sobald eine Aufnahme von der DVB-T gestartet wird, oder ich den VDR auch mal einfach nur ein paar Stunden auf einem DVB-T Sender "stehen lasse", dann kommen die selben Fehlermeldungen.

Ich habe gerade testweise mal zwischen 2 Transpondern wild hin- und hergezappt und dadurch nach ca. 50-60 mal umschalten dieselben Fehlermeldungen bekommen.
Zwischen Kanälen auf dem selben Transponder kommen die Meldungen nicht.

Wenn die Fehlermeldung kommt, ist es meist noch möglich zwischen den DVB-T Kanälen zu wechseln und zu schauen, aber sobald ein DVB-C Sender ausgewählt wird, bleibt das Bild schwarz, trotz Bombensignal (laut FEMON).

Ich werd den patch auch mal ausprobieren, diverse Treiberversionen habe ich schon ausprobiert.

Edit: Ich verstehe nicht, warum der Arm crashed. Was heisst das genau? Stack oder Irgendein Puffer-überlauf? Warum crashed der überhaupt, wenn er "falsche Daten" bekommt? Müsste doch eigentlich durch die Firmware abfangbar sein...
Ist die Firmware OpenSource? Wenn ja, wo krieg ich die?

Bei mir sieht exakt so aus wie bei Xyphro. Nur zum Glück nicht so oft. Wenn das alle 50..60 mal passier4t ist das ja schon fast unbrauchbar.

Der Fakt hingegen bleibt:
nach Umschalten von DVB-t auf DVB-C (also wenn der Transfermode verlassen wird)
im Übrigen passiert das auch manchmal wenn ich von analog auf DVB-C umschalte

Tach,

da ich das mit den makelinks und getlinks-Geschichten für den DVB-Treiber nicht wirklich so richtig hinbekommen habe, gerade beim Ändern von Kernel gabs dann immer blöde Fehlermeldung beim Kompilen, habe ich dann irgendwann den 2.6.10er als gentoo-ebuild installiert und die aktuellste (Version d irgendwas-Firmware) ins entsprechende Verzeichnis kopiert. Als DVB-Treiber benutze ich die aus dem Kernel.

Mein System ist hinlänglich bekannt und besteht jetzt wieder aus der Schmerzgrenzenlösung mit 1 x Nexus-S, 3 x Nova-SE (stv0299) Frontend und einer PVR 350. VDR-Technisch läuft hier 1.3.17.

Fürs DVB-Treibertesting wohl die Extremsolution Grundsätzlich kann ich so schon mal sagen, dass die Nexus für sich alleine oder auch mit nur einer Nova recht stabil läuft.

Das Zapping ist zwar was langsamer als früher und gerade, wenn man eine Aufzeichnung sich anschaut und dann die Wiedergabe beendet, braucht es oftmals recht lange (3-4 Sek.), bis das Live-TV-Bild wiederkommt. Auch wenn man von Kanal 500 auf Kanal 1 schaltet, dauert es nen bisserl. Von einem zum nächsten gehts eigentlich recht flott.

Im Normalbetrieb gibt es nicht wirklich viel zu meckern. Live-TV schauen und die Wiedergabe von Aufzeichnungen sind soweit okay. Zumindest für die meiste Zeit.

Beim Booten jedoch kommt es mitunter vor, das Kabel1, Sat1, ProSieben sich durch nette Artefakte und Klötzchen negativ hervorheben. Auch ist es mir schon mal passiert, dass das Bild ruckelt, der Ton weiterläuft. Was ganz schlimm ist, sind jedoch "Sprünge", da hakt irgendwo der Buffer. Das sieht so aus, dass man eine 3-4 Sekunden lange Szene (oftmals auch durch Störungen verunstaltet) mehrmals wiederholt hintereinander sieht, und dann das Bild wieder ne Weile normal weiterläuft, bis sich das Phänomen des "Szenensprungs" erneut wiederholt. Nimmt man in diesem Zustand etwas auf, ist die Aufnahme gleichfalls "versaut".

Rebootet man den Rechner daraufhin (kompletter Warmstart !) kann man erstaunt sein, dass das Phänomen mit einem Mal wieder weg ist. ARD, ZDF, RTL und viele andere Sender sind hiervon bislang überhaupt nicht betroffen.

Stichwort: Parallele Aufnahmen. Ein 4-Karten-System verleitet natürlich dazu, den letzten Schrott aufzunehmen, weil man ja entsprechende Resourcen hat. Nichtsdestotrotz sind hier in dieser Kernel-Treiber-Architektur auch enge Grenzen gesetzt.

Eine bis zwei Aufnahmen machen normalerweise keine Probleme. Kritisch wird es ab 3-4 gleichzeitigen Aufnahmen. Vor allem dann, wenn man ProSieben und einen der anderen obig erwähnten Sender mit aufnehmen will. Gerade am Sonntag, wenn Enterprise kommt, verzichte ich, zusätzlich zu einer meiner Lieblingsserien nochwas anderes mit aufzunehmen

Ab 4 isses allerdings vorbei. Bei nur 2 Karten hab ich neulich beim Testen auch schon mal 12 (!!!) parallele Recordings geschafft, da wurde aber die Steuerung dermassen lahm, dass es nicht wirklich mehr Spass machte. Auch war dann irgendwann das Live-TV-Bild komplett weg und wechselte ins absolute Schwarz.

Man kann Glück haben, dass die Kiste nicht abstürzt und der Watchdog zuschlägt, es kann aber auch genausogut nen Reboot geben. Feste Regeln gibst da keine.

Was auch ganz witzig ist, man schaut sich eine Aufnahme an, macht nen Standbild und schläft vor Müdigkeit ein. Wenn dann ne Aufnahme noch ansteht, kann man die wohl vergessen, zumindest wars bislang immer so. Ob das jetzt mit dem Standbild im Zusammenhang steht oder eher was mit dem idle-Betrieb was zu tun hat, nope ?!

Jedenfalls taucht dann auch schon mal sowas hier auf...

Dec 28 00:58:50 vdrclient01 vdr[16820]: initiating emergency exit
Dec 28 00:58:50 vdrclient01 vdr[16770]: emergency exit requested - shutting down
Dec 28 00:58:54 vdrclient01 vdr[16770]: emergency exit!

Was man allerdings positiv erwähnen muss, ist das absolute Fehlen von unknown picture type errors zumindest in meinen Logfiles. Mit 2.6.8er, 9er und früheren 10er Kernel hatte ich die alle 2-3 Tage.

Vielleicht besteht ja wirklich auch noch ein Zusammenhang zwischen der Anzahl der Karten im System. Nach dem Motto: weniger Karten gleich weniger Ärger.

Oder es ist problematisch, wenn alle Karten, wie bei mir, das gleiche Frontend (STV0299) verwenden.

Die schönsten Fehlermeldungen noch hinterher...

Dec 28 13:30:56 vdrclient01 vdr[9518]: ERROR: device 1 has no lock, can't attach receiver!

Dec 28 01:05:36 vdrclient01 vdr[19224]: ERROR: video data stream broken
Dec 28 01:05:37 vdrclient01 vdr[19355]: ERROR: driver buffer overflow on device 1
Dec 28 01:05:37 vdrclient01 vdr[19354]: ERROR: skipped 153 bytes to sync on TS packet on device 1

Dec 28 01:05:29 vdrclient01 vdr[19356]: ERROR: driver buffer overflow on device 1

Dec 27 15:53:45 vdrclient01 vdr[18435]: ERROR: channel data not unique!
(hat wohl nix mit dem Treiber zu tun)

Dec 27 15:41:43 vdrclient01 vdr[14086]: ERROR: (null): Bad address

Dec 28 13:31:13 vdrclient01 dvb-ttpci: av7110_fw_cmd error

Dec 28 13:31:12 vdrclient01 dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error

Dec 28 13:31:10 vdrclient01 dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle

Dec 26 16:28:57 vdrclient01 __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE

Es ist alles da Das ganze Programm...

Ermutigenderweise muss man aber sagen, dass im normalen, abendlichen Alltagsbetrieb die Systemstabilität mir persönlich ausreicht. Als Perfektionist und natürlicher Feind von unangenehm, klingenden Fehlermeldungen bin ich natürlich noch nicht restlos glücklich. Irgendwo machts ja auch keinen Sinn, 4 DVB-Karten zu haben und die gar net nutzen zu können bzw. nicht im Einklang wirklich ROCK-STABLE zu bekommen. Damit meine ich, unkaputtbar. Stabil als solches ist die momentane Geschichte ja schon, sieht man mal von Mehr-als.4-Spur-Parallelrecording ab

Greets Olaf

P.S.: Na, es kann nur besser werden. Auf jeden Fall hat sich meiner Ansicht nach doch schon sehr viel getan, was die Laufstabilität der Treiber anbelangt. Es tut gut zu sehen, dass sich hier wohl ein absolutes Crack-Superteam zusammengetan hat, das für uns versucht, alle Probleme in den Griff zu bekommen. Das es aber noch viele Probleme gibt, hat meiner laienhaften Meinung aber nicht nur mit dem DVB-Treiber, sondern sicherlich auch mit dem 2.6er Kernel an sich zu tun, denke ich mir zumindest mal, ohne es zu wissen...leider.

also nochmal hier nach dem patchen nix mehr mit fehlermeldung !!!!!
schnelsstes zappen moeglich !!
allerdings mein system 2xdvb-c siemens 1xdvb-t avermedia 771

Hab auch gepatcht, sieht bisher gut aus, weil es den extrem-zapping-test bestanden hat.

Jetzt bin ich erstmal gespannt, ob es nach ein paar Stunden DVB-T gucken wieder crashed...

Danke schonmal für den Patch

neumann2k:

Dein patch macht

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

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) {

sein?

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

Beide male kommt sowas:

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...

ich hab so das gefuehl, dass es abhaengig ist vom empfang.
ich bekam die fehlermeldung erst wieder als ich die antenne ausgesteckt hab

Wenn ich die Antenne abstecke kommt auch nach ein paar Sekunden die bekannte Meldung...

Mit der "besten" Antenne (aktive Stabantenne) bekomme ich ein SNR von ca. 85%, STR ist immer, egal was für eine Antenne ich anschliesse bei 8%.

Ich bin im DVB-T Kerngebiet, keine 20km Luftlinie vom Sender in Wesel entfernt...

Was habt ihr denn so?

na ja luftlinie 3km richtung sender.
vom fenster direkte sicht zum sender.
bietet sich an

Wo muß den der Patch hin?

Gruß Deejenda

Also ich hab mir vdrdevel-experimental als sourcen von Tobis repsitory besorgt:

cd /usr/src
apt-get source vdrdevel
cd vdrdevel-1.3.17/

Dann die transfer.c patchen oder von Hand anpassen

dann:
debian/rules binary

cd ..

dpkg -i vdrdevel-???????????.deb