05.12.2005 - AV7110 Firmware mit RICHTIGES LiveAC3 - ff-2622 - von Werner (neuer als fb-2621)


  • Quote


    Vielleicht findet sich noch eine einfachere Methode, die richtige Reihenfolge zu erzwingen.


    Die einfachste ist wohl der Ansatz über das RPBusy Bit, wie das von lordzodiac
    mit seinem Treiber und meiner neusten firmware verwendet wird. Liest Marco
    eigentlich mit? Immerhin diskutieren wir das ja auch per PM und Du stehst im CC :D


    Quote


    Verschwindet das Problem eigentlich, wenn die fraglichen Kommandos durch entsprechend große msleep()-Befehle voneinander getrennt werden?


    Gute Frage.


    Werner

  • Hallo,


    ich lese mit. ;)


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

  • Quote

    Original von bitstreamout
    Immerhin diskutieren wir das ja auch per PM und Du stehst im CC :D


    Stimmt. Nur fehlt mir halt irgendwie die erste Mail, wo das Problem beschrieben wurde.
    Ich lese dauernd was von Lösungsansätzen, nur zu welchem Problem genau eigentlich? :alki
    Gut, nach der letzten Mail ist es etwas klarer. Ich weiß aber immer noch nicht, was ich tun muß, um es auszulösen...


    Quote


    Gute Frage.


    Falls es hilft, ist es tatsächlich eine Race-Condition zwischen aufeinanderfolgenden Befehlen, andernfalls doch etwas anderes.


    CU
    Oliver

  • Quote

    Original von Frank99
    Hallo,


    sorry wollte keinen extra Thread aufmachen,


    Wäre aber besser gewesen. :P

    Quote


    kann das sein das momentan die DVB CVS Treiber brocken sind?


    Es stimmt zwar, daß der CVS-Treiber ein ziemlicher Brocken ist, aber 'broken' ist er derzeit eigentlich nicht. SCNR :D



    Bei mir gibt's das alles. Könnte es sein, daß Deine Kernel-Sourcen nicht konfiguriert sind (make config) und Du den Kernel noch nie übersetzt hast?


    CU
    Oliver

  • Hallo Oliver,


    das Problem haben wir hier.


    http://www.vdr-portal.de/board/thread.php?threadid=26885&sid=


    Auslösen kann man den Fehler nach folgendem Muster.
    Als erstes lade ich die Treiber.
    Vdr muß dann beim starten gleich im Transfermodus arbeitet.
    Man darf dann 30-45 Minuten nicht umschalten.
    Danach löst dann zu 90% das erste __STOP Kommando einen Timeout aus. Danach lösen dann die Folgekommandos auch Timeout's aus.
    Um so schneller man dann umschaltet um so mehr Timeout's werden dann ausgelöst.


    Marco


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

  • Habe mir gerade die Firmware testweise installiert.
    Habe zwar kein AC3, aber es schien mir, als ob es weniger Bildaussetzer und ein schnelleres Umschalten gäbe.
    Aber...


    Nach kurzer Zeit mit vdr-1.3.27 mit bigpatch und DeepBlue gab es folgende Meldungen:


    Hat das sonst auch wer?
    lg, Gerhard

  • Quote

    Original von gestein

    Code
    21:55:42 stonevdr kernel: dvb-ttpci: warning: timeout waiting in BlitBitmap()
    21:55:52 stonevdr kernel: dvb-ttpci: warning: timeout waiting in BlitBitmap()


    ich würde einfach mal ein paar Tage warten, da ist Work in Progress. An der Firmware und am Treiber.

  • Hab gerade das Update gemacht.
    Mein Problem scheint behoben zu sein.


    Wie merke ich eigentlich, dass die richtige Firmware benutzt wird?


    Im syslog steht z.b.

    Quote

    DVB: AV7111(0) - firm f0240009, rtsl b0250018, vid 71010068, app c000261e


    lg, Gerhard


  • Quote

    Original von bitstreamout
    Hallo,


    wie gehabt unter http://www.suse.de/~werner/test_av.tar.bz2


    Werner


    Und wieder ne 261e die irgendwie "anders" ist :D


    Habe übrigens bisher kein glück mit den versionen nach 261d unter ctvdr3.
    Das system wird deutlich instabiler. Inbesondere hab ich des häufigerem hänger hach beendigung einer aufnahme oder nach dem abspielen einer aufnahme.
    Patchen der treiber ist leider nicht so ohne weiteres möglich unter ctvdr.


    gruss Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

  • Quote

    Original von PeterD
    Und wieder ne 261e die irgendwie "anders" ist :D


    Also wen nich ejdesmal die Versionsnummer erhöhe, wenn ich
    was teste, wären wir schon wesentlich weiter, jedenfalls mit
    der Versionsnummer :D


    Quote


    Habe übrigens bisher kein glück mit den versionen nach 261d unter ctvdr3.
    Das system wird deutlich instabiler. Inbesondere hab ich des häufigerem hänger hach beendigung einer aufnahme oder nach dem abspielen einer aufnahme.
    Patchen der treiber ist leider nicht so ohne weiteres möglich unter ctvdr.


    Und das gilt auch mit der derzeitigen firmware 0x261e (1.18 )?


    Werner

  • Hi,


    ich hab auch mal die Firmware vom 26.05. und 10.06. getestet (ohne AC3).


    Mit der Firm vom 10.06. hab ich das Problem das mplayer nicht mehr mag, in diesem Fall Divx. Mplayer startet zwar, aber spielt nicht ab, und nach dem beenden der Wiedergabe hängt sich vdr weg...mit der Firm vom 26.06. passiert das nicht.


    CVS Treiber vom 23.06.05


    Gepatched hab ich am Treiber nichts, und an vdr nur einige eigene Sachen.


    Andy

  • Quote

    Original von bitstreamout


    Und das gilt auch mit der derzeitigen firmware 0x261e (1.18 )?


    Die ganz neue hab ich noch nicht ausprobiert.
    Bisher hab ich das auch noch nicht systematisch verfolgt.
    Es kann durchaus sein das der treibertausch mitverantwortlich ist.
    Um das dvd audioproblem zu lösen ist halt 261d oder höher nötig. Dazu braucht man bei ctvdr den neueren treiber inklusive hotplug firmware.
    (wobei ich nicht verstehe das man eine neue firmware braucht um wieder audio bei dvd umschalten zu können, da stimmt wohl was in vdr+plugin noch nicht)


    Jedenfalls hat mit den bisherigen versionen in der hotplug version die stabilität gegenüber einer einkompilierten 261c gelitten.


    Ich werd das nach meinem Urlaub noch mal systematischer angehen und eventuell auch mal versuchen die treiber zu patchen.
    Es sieht so aus das die neuen warte modi mit dem ungepatchten treiber seiteneffekte ergeben, da viele probleme zusammen mit text2skin aufzutreten scheinen insbesondere in verbindung mit den bereits diskutierten verzögerung beim displayaufbau von text2skin.


    gruss Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

  • Habe seit gestern die aktuelle Version im Einsatz:
    Ergebnis nach einiger Zeit des Betriebs:



    Steige wieder auf die alte version um und probier dann die nächste wieder :)


    lg, Gerhard

  • Quote

    Original von gestein
    Habe seit gestern die aktuelle Version im Einsatz:
    Ergebnis nach einiger Zeit des Betriebs:



    Steige wieder auf die alte version um und probier dann die nächste wieder :)


    Das riecht nach einem Temperaturproblem. Die neue firmware benutzt
    sehr viel die ARM CPU, jedenfalls mehr als die alte um schneller zu
    synchronisieren.


    Werner

  • Quote

    Original von PeterD
    Um das dvd audioproblem zu lösen ist halt 261d oder höher nötig. Dazu braucht man bei ctvdr den neueren treiber inklusive hotplug firmware.
    (wobei ich nicht verstehe das man eine neue firmware braucht um wieder audio bei dvd umschalten zu können, da stimmt wohl was in vdr+plugin noch nicht)


    Wegen AC3 loop through Support via DVB-Karte.


    Quote


    Jedenfalls hat mit den bisherigen versionen in der hotplug version die stabilität gegenüber einer einkompilierten 261c gelitten.


    Ich benutze die neue firmware mit einem alten linux-dvb Treiber und einem
    2.4er Kernel. Es ist bombenstabil, nur die Kühlung der DVB-Karte sollte
    für AC3 replay gut genug sein :D


    Werner

  • Quote

    Original von bitstreamout


    Wegen AC3 loop through Support via DVB-Karte.


    Hat damit nichts zu tun.
    Mit 261c funktioniert nachweislich nur der erste audio stream. Alle anderen bleiben stumm. Die streams sind aber alle AC3.
    Bis 1.3.20 (unsicher kann auch 22 gewesen sein) ist das verhalten ähnlich. Man kann aber den ton im dvd menü umschalten. Wenn man jetzt aber während des films die audio taste benutzt geht plötzlich nur noch stream 1 obwohl vorher steam 2..n ton hatte.


    Anscheinend vertut sich vdr+plugin dabei was weitergereicht wird oder meldet die falsche codierung. Die AC3 codierung des streams ist meiner meinung nach nicht schuld.


    Quote

    ... nur die Kühlung der DVB-Karte sollte für AC3 replay gut genug sein :D


    gut zu wissen . . .


    gruss Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

    Edited 2 times, last by PeterD ().

  • Hallo,


    mit den ersten 261e-Versionen hatte ich ständig


    Code
    Jun 23 20:26:18 video1 kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1


    Das ist heute mit der neuen 261e und den CVS Treibern von heute Nachmittag noch nicht aufgetreten.


    Eine andere Fehlermldung gibt es aber weiterhin, die ich mir 261d nicht habe:



    Hat das folgende eigentlich irgendetwas damit zu tun? Worum geht es da?


    Code
    Jun 24 20:01:08 video1 vdr[4769]: read incomplete section - len = 570, r = 647

    VDR1: Gigabyte GA-M720-US3 (nVidia Corporation MCP78S [GeForce 8200]), Athlon II X2 240, 2GB RAM, Intel 82574L Gigabit, Debian Squeeze, Kernel 2.6.38.3 mit linux-media.tar.bz2 vom 20.04. 10:04, dvbhddevice fb6b1beedb72, VDR-1.7.22 (extension-Patch, 15 Plugins), epgsearch, extrecmenu, ...
    VDR2: Debian Etch, 2.6.21.3, K6-2 400, 192MB, NFS-Root, 466GiB über NFS, 1xNexus 2.1, 1xNova S, VDR-1.4.7
    Server: Debian Squeeze, 2.6.35.7, AMD X2 240e, 4GB, System: Raid1 2x500GB, Aufnahmen: Raid5 4TB + 1x 500GB, 1000MBit LAN
    Episodenlisten für epgsearch, VDRSeriesTimer

  • Quote

    Original von vejoun
    Hallo,


    mit den ersten 261e-Versionen hatte ich ständig


    Code
    Jun 23 20:26:18 video1 kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1


    Das ist heute mit der neuen 261e und den CVS Treibern von heute Nachmittag noch nicht aufgetreten.


    so soll es sein


    Quote


    Eine andere Fehlermldung gibt es aber weiterhin, die ich mir 261d nicht habe:


    Code
    Jun 24 19:25:49 video1 kernel: av7110_fw_request: timeout waiting for COMMAND to complete
    Jun 24 19:25:49 video1 kernel: dvb-ttpci: StartHWFilter error  buf 0b07 0010 0068 b96a  ret -110  handle c03e
    [...]
    Jun 24 20:57:22 video1 vdr[4769]: buffer usage: 90% (tid=-1392866384)
    Jun 24 20:57:23 video1 vdr[4769]: buffer usage: 0% (tid=-1392866384)


    Hat das folgende eigentlich irgendetwas damit zu tun? Worum geht es da?


    Code
    Jun 24 20:01:08 video1 vdr[4769]: read incomplete section - len = 570, r = 647


    Darum, dass im Treiber ungeklärt timeouts nach Lesebefehlen auf Register
    der DVB-Karte oder besser des SAA7146 auftreten, die definitv nicht von
    der firmware noch von SAA7146 auf der DVB-Karte stammen ... denn dann
    müsste ich das auch mit dem alten linux-dvb Treiber und einem 2.4er Kernel
    sehen und genau das tue ich nicht.


    Aber wir jagen ihn, den Bug :D


    Werner

  • Hallo


    Haben diese StopHWFilter Fehlermeldungen evtl etwas mit der Last auf dem System zu tun ? Zur Erklärung.


    Ich habe 2 VDR Systeme, einen Server mit 2 FF Karten der gleichzeitig noch Fileserver u.s.w. ist. Der läuft rund um die Uhr. Bei diesem System treten massenweise dieser StopHWFilter Fehler auf. Ist das System unter last treten diese Fehler deutlich häufiger auf als wenn der Idle ist. Diese Fehlermeldungen bewirken bei mir übrigens sonst nichts negatives, VDR läuft Stable und auch die Aufzeichnungen sind ok. An diesem Server wird übrigens nicht Live geschaut und kein OSD genutzt, der ist nur zum streamen und Aufnehmen.


    Mein 2tes System ist ein HDD loser Client mit einer FF Karte. Dieses System ist eigentlich immer Idle und hier habe ich diesen Fehler noch nie gesehen.


    Beide Systeme laufen unter Debian Sarge mit Vanilla Kernel 2.6.12 und Firmware 261d.


    Und dann gleich noch eine Frage, muss das eigentlich so sein das sich der Treiber aufhängt wenn auf einem getuneten Transponder plötzlich kein Signal mehr kommt ? Oder ist es der VDR Selbst der in so einem Fall neu startet und dabei die Treiber neu läd ?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!