[ANNOUNCE] Avards-Plugin 0.1.5

    Hallo,

    ich habe ein paar kleinere Änderungen in Avards eingepflegt.

    Das Avards-Plugin dient zur automatischen Erkennung und Unterdrückung der schwarzen Ränder bei der Ausstrahlung von Breitbild-Material im 4:3-Modus (Letterbox-Format), indem dem Fernseher über das WSS-Signal ein Zoomfaktor mitgeteilt wird.

    Die wichtigsten Änderungen zwischen Avards 0.1.4 und 0.1.5:
    -------------------------------------------------------------
    - französische Übersetzung hinzugefügt (Danke an Patrice Staudt)
    - Kommandozeilen Parameter -q hinzugefügt für non-Standard WSS-Code 0x0e (insbesondere für Samsung TV interessant, siehe REAMDE)
    - italienische Übersetzung hinzugefügt (Danke an Diego Pierotto)
    - Hysterese korrigiert, die bei der Code-Restrukturierrung verloren gegangen war (Danke an e9hack)

    Hier geht es zur Homepage
    und hier direkt zum Download

    Happy compiling
    FireFly

    Hallo FireFly,

    ich bin vor kurzem auf dein Plugin gestoßen und wollte es bei mir einsetzen.
    In der kurzen Zeit in der es bei mir funktioniert, schaltet es sauber um und ich bin eigentlich begeistert.
    Leider kommt es nach kurzer Zeit bei Aktivierung des Plugins zu einem Absturz und in Folge zu einem Kernel Oops...

    Zum System:
    - Minimalsystem mit busybox und nur den nötigsten libs,
    - Vanilla-Kernel 2.6.29 und 2.6.28.8 mit allen Treibern einkompiliert bis auf lirc,
    - Vanilla-VDR 1.6.0.2 nur mit dem avards-plugin,
    - glibc2.8
    - kein udev, alle Devices sind vorher per mknod angelegt worden,

    Die Abstürze kommen nur, wenn die Erkennung aktiviert wird. Bis zum Absturz funktioniert das Plugin aber und der Fernseher schaltet sauber um.

    Hat jemand Ideen was zu dem Absturz führt, bzw. kann ich noch irgend welche Daten zur Verfügung stellen?

    Achso, Speicher ist getestet und die üblichen Kandidaten an Hardware für Abstürze, würde ich ausschließen, da das System sonst stabil ist.

    Viele Grüße
    heifisch

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Einmal editiert, zuletzt von heifisch (27. März 2009 um 18:06)

    Hei heifisch :)

    ich habe bisher maximal Kernel 2.6.27 eingesetzt und keine Probleme festgestellt (ich habe keine DVB-S2 Karte und wollte mir den S2API-Treiber deshalb bisher nicht antun :D). Es ist nicht auszuschließen, dass noch ein Bug in den neueren Treibern ist.
    Evtl. hast Du aber auch das gleiche Probleme, das steini hier mit/ohne udev beschrieben hat.

    Aus dem Call Trace kann ich nichts bestimmtest rauslesen, vielleicht jemand anderes? Evtl. würde es auch helfen, alle Avards-Meldungen vom Start des VDR bis zum Crash zu haben um herauszufinden, unter welchen Bedingungen der Fehler auftritt, z.B. nur bei bestimmten Moduswechseln.
    Auf der anderen Seite macht mich das StopHWfilter etwas stutzig, das sieht mir eher nach Kanalwechsel aus als ein Avards-Systemcall. Welchen Treiber setzt Du denn ein? Die original Kerneltreiber?

    FireFly

    Moin Moin,

    danke für die schnelle Antwort.
    Hab gerade gemerkt, dass ich doch etwas sparsam mit Informationen war...

    Es handelt sich um eine TT DVB-S FF Karte 1.6.

    Die Treiber sind die original im Kernel enthaltenen.

    Auszug aus .config:

    Ich werde mich mal mit gdb beschäftigen. Vielleicht kann ich noch ein paar mehr Informationen rausholen.

    Die 10 Sekunden, in denen das Plugin bei mir funktioniert, haben mich begeistert.
    Irgendwie muss das bei mir gehen ;)

    Ich melde mich noch mal wenn ich mehr Infos habe...

    heifisch

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    nabend

    Ich nutze mal diesen Thread für ne Frage.

    Ich besitze seit heute einen Plasmafernseher von Panasonic. Nache einigem suchem habe ich dann von dem Avards-plugin erfahren und erfreulicherweise eine Version (1.5.1) für meinen ctvdr gefunden. (Lenny)

    Leider zickt es bei mir, wie auch schon in einem anderen tread angesprochen rum.

    Der Vdr beginnt nach wenigen Sekunden an, wild umzuschalten, als wenn jemand auf der Fernebedienung sitzt. Abdecken oder zuhalten des Lirc-empfängers ändert nichts. Erst nach vdr-Neustart ist wieder ruhe.

    Das Log gibt nichts aus, was das avards-plugin betrifft.
    nur: ERROR: cKbdRemote: Ungültiger Dateideskriptor in vielfacher Folge.

    Ich kann mir da keinen Reim drauf machen. Kennt jemand diesen Effekt und weiss was man tun kann?

    Danke
    Cat

    "Life moves fast. Don't miss a thing."
    ------------------------------------------------------
    Rechner: Celeron 2,666 Ghz; 256 SDRAM, TT rev. 1.6 +Satelco Easywatch ,1x 160GB Samsung Festplatte, 1 x 500 GB WD
    Gehäuse : LaScala03 (Silverstone),Zalman CNPS 7000CU .Asus P4S533-MX; AVBoard 1.0 
    CTVDR ( Lenny)

    Einmal editiert, zuletzt von catweazle (28. März 2009 um 23:56)

    Zitat

    Original von catweazle
    Ich kann mir da keinen Reim drauf machen. Kennt jemand diesen Effekt und weiss was man tun kann?


    Hatte ich auch schon einige Male. Das Log hat dann sowas ausgespuckt:

    Zur Ursachenforschung kann ich leider nix beitragen.

    VDR-User #992
    Server: Asrock N3700-ITX mit Cine S2 6.5 headless
    System: Ubuntu 22.04.LTS
    VDR: VDR 2.2.0 mit epgsearch, live, vnsiserver
    Client: Raspberry Pi v4 mit LibreElec

    die avards meldungen habe ich nicht. Es funktioniert ja auch kurz. Aber dann fängts an mit dem Umschalten. die anderen Meldungen sind identisch.

    Sehr seltsam. Aber ich steh ja nicht alleine da ;)
    Danke
    Cat

    "Life moves fast. Don't miss a thing."
    ------------------------------------------------------
    Rechner: Celeron 2,666 Ghz; 256 SDRAM, TT rev. 1.6 +Satelco Easywatch ,1x 160GB Samsung Festplatte, 1 x 500 GB WD
    Gehäuse : LaScala03 (Silverstone),Zalman CNPS 7000CU .Asus P4S533-MX; AVBoard 1.0 
    CTVDR ( Lenny)

    Zitat

    Original von Sledge Hammer


    Hatte ich auch schon einige Male. Das Log hat dann sowas ausgespuckt:

    Zur Ursachenforschung kann ich leider nix beitragen.

    Das könnte ein Bug im avards-Plugin im Umgang mit File-Descriptoren sein. Die werden teilweise nicht korrekt initiallisiert bzw. es werden nichtinitiallisierte Descriptoren geschlossen. Normalerweise sind alle Descriptoren >= 0 gültig. Das Plugin fragt gelegentlich auf >0 ab bzw. schließt uninitialisierte Descriptoren, die dann den Wert 0 haben. Wenn später vom Vdr auf den Descriptor 0 zugegriffen wird, kann das zu verwirrenden Fehlermeldungen führen.

    Gruß
    e9hack

    danke für deine Meldung. Ist mir leider zu hoch ;) Aber wenn du meinst, dass das Plugin einen Fehler hat bzw. aufdeckt, gibts ja hoffnung, dass das jemand fixt.

    thx
    Cat

    "Life moves fast. Don't miss a thing."
    ------------------------------------------------------
    Rechner: Celeron 2,666 Ghz; 256 SDRAM, TT rev. 1.6 +Satelco Easywatch ,1x 160GB Samsung Festplatte, 1 x 500 GB WD
    Gehäuse : LaScala03 (Silverstone),Zalman CNPS 7000CU .Asus P4S533-MX; AVBoard 1.0 
    CTVDR ( Lenny)

    Hallo FireFly,

    ich hab nochmal Kernel 2.6.27.20 mit den internen Treibern probiert.
    Leider stürzt da der VDR auch bei Aktivierung der Erkennung immer ab :(
    Mit gdb hab ich leider auch nicht mehr Informationen rauskitzeln können.
    Bin da auch nicht so Fit was den Umgang damit angeht...
    Weiß dann auch nicht wie man dem Fehler auf die Spur kommen kann...

    Gibt es da noch Ideen?

    Viele Grüße

    heifisch

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    würd ich gern.. aber ich nutze ctvdr und bin von Tobis paketen abhängig. Das kompilieren hab ich zuletzt vor 2 Jahren mal gemacht.

    Trotzdem danke

    Gruss
    Cat

    "Life moves fast. Don't miss a thing."
    ------------------------------------------------------
    Rechner: Celeron 2,666 Ghz; 256 SDRAM, TT rev. 1.6 +Satelco Easywatch ,1x 160GB Samsung Festplatte, 1 x 500 GB WD
    Gehäuse : LaScala03 (Silverstone),Zalman CNPS 7000CU .Asus P4S533-MX; AVBoard 1.0 
    CTVDR ( Lenny)

    hi,

    hier hatte ich ein Problem mit meinem VDR. Die Version 0.2.2-1 des Plugins war installiert und der VDR-Prozess wurde irgendwann von oom_killer gestötet.

    Hat kein andere diese Probleme? Handelt es sich möglicherweise um eine Unverträglichkeit mit anderen Plugins?

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    Ich habe mir in der Zwischenzeit das Problem etwas genauer angesehen. Bei mir kommt mit avards 0.2x das System nach einigen Stunden ins Pagen und ist kaum noch bedienbar. Vorläufige Analyse:
    Der Unterschied zwischen avards 0.1.x und 0.2.x ist wohl, das bei den neueren Versionen der VIDIOC_REQBUFS-ioctl und der mmap in der Active()-Schleife gemacht werden, während sie vorher nur einmal gemacht wurden.
    Es sieht jetzt so aus, als ob der mmap unkritisch ist und von munmap alles wieder richtig freigegeben wird, aber der von REQBUFS für die im Treiber angelegte Warteschlange verbrauchte Speicher nie wieder freigegeben wird. Entgegen der V4L2-Spezifikation nutzt auch ein REQBUFS-Aufruf mit count=0 nichts, da der Aufruf mit EINVAL quittiert wird.
    In avards ist das nur zu umgehen, wenn wieder wie früher der REQBUFS nur einmal beim Starten des Detektors gemacht wird.
    Vorher würde ich empfehlen, avards nicht automatisch zu starten, sondern nur bei Bedarf laufen zu lassen (bei 16:9 macht es sowieso nichts und bei 4:3 ohne Letterbox arbeitet es zwar kräftig, beläßt aber das Format).
    Die Korrektur müßte im v4l2-Treiber stattfinden, da auch nicht mal ein Device-close() oder ein Entladen die Situation zu bereinigen scheint.

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Zitat

    Original von TomJoad
    Es sieht jetzt so aus, als ob der mmap unkritisch ist und von munmap alles wieder richtig freigegeben wird, aber der von REQBUFS für die im Treiber angelegte Warteschlange verbrauchte Speicher nie wieder freigegeben wird. Entgegen der V4L2-Spezifikation nutzt auch ein REQBUFS-Aufruf mit count=0 nichts, da der Aufruf mit EINVAL quittiert wird.


    Das ist mir auch schon mal aufgefallen (s. http://www.spinics.net/lists/linux-media/msg00460.html). Die DVB-Entwickler waren nicht wirklich dran interessiert.

    [edit]
    Du kannst ja mal folgenden Patch probieren:

    [/edit]

    Eigentlich ist es für Avards unproblematisch, da bei jedem REQBUFS-Aufruf mit count>0 die vorherige Warteschlange komplett freigegeben wird.

    Gruß
    e9hack

    Einmal editiert, zuletzt von e9hack (18. September 2009 um 10:30)

    Ich hoffe, ich habe jetzt den nötigen Patch gefunden. Beim saa7146 wird saa7146_pgtable_free immer nur vor saa7146_pgtable_alloc aufgerufen. Das funktioniert aber nur dann, wenn vom letzten Aufruf in videobuf_buffer/saa7146_buf noch die alten Pointer stehen. Wird in der Schleife videobuf_buffer immer wieder freigegeben und von REQBUFS neu allokiert, sind die alten Pointer weg und pgtable_free macht nichts.
    Folgender Treiberpatch hat die ersten Tests positiv überstanden:

    Diff
    --- a/saa7146_video.c   2009-04-17 21:42:35.000000000 +0200
+++ b/saa7146_video.c   2009-09-22 09:03:50.000000000 +0200
@@ -1331,6 +1331,7 @@ static void buffer_release(struct videob
 
        DEB_CAP(("vbuf:%p\n",vb));
        saa7146_dma_free(dev,q,buf);
+       saa7146_pgtable_free(dev->pci, &buf->pt[0]);
 }
 
 static struct videobuf_queue_ops video_qops = {


    Der Patch sollte aber noch erweitert werden auf pt[1] und pt[2] für den Fall IS_PLANAR, mir ging es nur ums Prinzip

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Hmm... Hab den Patch gerade mal ausprobiert. An meinem Problem verbessert er leider nichts.
    Immer noch kurze Zeit nach Aktivierung von avards ein Oops...

    Wenn ich irgend etwas beitragen kann, den Fehler zu beseitigen, so will ich das gerne tun.
    Brauche nur etwas Führung...

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Die Probleme von fossy und heifisch müssen nicht die gleiche Ursache haben. Wenn man sich die Problemadressen in den oops-Protokollen ansieht, sieht es eher nach einem Kernelüberschreiber aus.
    Mein Problem und vielleicht auch das von fossy tritt erst nach längerer Zeit auf, weil es eine Weile (im Bereich von Stunden auch bei 256MB Hauptspeicher) dauert, bis kein Speicher mehr frei ist.

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden