Posts by m.Rcu

    also die "mem" Zeile im grab speichert ja das Bild im Speicher für den VDR. Entweder würde man das für die alten jpeg Versionen nochmal komplett selber implementieren.


    oder man ersetzt im Makefile

    Code
    1. CONFIG += $(shell ls /usr/lib/libjpeg* >/dev/null 2>&1 && echo "-DUSE_JPEG



    durch


    Code
    1. CONFIG += $(shell echo -e "\#include \n\#include \n\#include \n void main (void){jpeg_mem_dest(NULL,NULL,NULL);}"|gcc -x c - -ljpeg -o /dev/null >/dev/null 2>&1 && echo "-DUSE_JPEG" )



    dann kompiliert es auch nur mit Jpeg wenn eine passender Version vorhanden ist ( was ja meiner Meinung nach für einen sehr grossen Teil zutreffen würde ??)

    Hi


    ich find das Plugin auch super. Hab mal einen Patch für die fehlende JPEG Grab Funktion angehängt.
    Ich musste bisher noch feststellen, dass über Nacht das Plugin manchmal wohl nicht richtig in den Suspend Mode geht.
    1 mal ging richtig, 10 std später dann eine Menge


    Code
    1. Jan 24 16:08:52 imap vdr: audio/alsa: broken driver 24Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189988/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189989/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189990/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189991/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189992/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189993/287720)



    svdrsend ... SUSP, schaltet sich die Ausgabe ab und das füllt nichts mehr ins Log. EIn Druck auf die Taste der FB läßt es dann ganz normal weiter spielen.
    Hat so etwas ähnliches noch jemand ? Find die Umschaltzeiten super schnell und würde daher auch gern dauerhaft auf dieses Plugin umschwenken.


    EDIT: update um ein kleines leak zu entfernen

    Files

    • jpeg.diff

      (4.61 kB, downloaded 67 times, last: )

    Ja kann ich dir kurz sagen, am einfachsten ist es in den Quellen vom Kernel (die musst du drauf haben) die Datein /usr/src/linux-(version)/drivers/media/dvb/dvb-usb/pctv452e.c editieren und die 2 Zeilen dort zu suchen und die Werte mit dem - durch die mit dem + ersetzen.


    Alternativ kannst du auch die patches runterladen und mit patch -p 1 < pctv452e.patch einbauen (-p kann auch -p 2 -p 3 oder -p0 sein, je nachdem wo du das genau machst)


    ich hoffe das hilft fürs erste


    Dann Kernel neu kompilieren , installieren und Module neu laden. Dann sollte es gehen

    Nach jeden neuen Kernel habe ich wieder erneut getestet, ob es nun mit 2 TT 3600 funkioniert. WIe zu erwarten ging es nicht. Seit 3.2 ist der Treiber nun direkt im Kernel. Leider auch mit den selbe Problemen. Aber es gibt auf der Mailingliste von linux-media einen Patch. Vor allem der letzte Teil mit den USB Parametern ist hierbei wichtig.



    @@ -1368,11 +1408,11 @@
    /* parameter for the MPEG2-data transfer */
    .stream = {
    .type = USB_ISOC,
    - .count = 7,
    + .count = 4,
    .endpoint = 0x02,
    .u = {
    .isoc = {
    - .framesperurb = 4,
    + .framesperurb = 64,
    .framesize = 940,
    .interval = 1
    }


    und ich kann sagen: 2 gleichzeitige Streams von den 2 TT 3600 laufen seit 30 min perfekt (vorher war schon nach 1 min wieder kaum was zu erkennen)


    Wäre schön, wenn Ihr das auch testen könntet. Und vor allem wenn das die Probleme nun endgültig bei allen löst.

    den branch vdpau-extensions-patch-xine-lib-patch" gibt es nur damit nicht jeder die patches von der xine mailing liste runterladen muss und von hand "einbauen". Wer die Patches selber einbauen will kann dies nat. immer noch selbst in den durchflieger branches tun. Sollte die Patches ins xine-lib hg einfliessen , wird der Branch wieder entfernt und man hat wieder eine besser Übersicht bei den Branches ;)

    so habe jetzt nochmal ein wenig getestet.


    kKötzchen kommen bei mir _immer_ sobal die Meldung auftaucht. (mit dem "laufenden" 2.6.33 nur ganz selten, dann ist das Bild meist OK, oder hat mal ein ganz kleines Klötzchen unten)


    mit plain 2.6.32 kriege ich gar kein Bild mehr hin (vdr startet, macht nur noch Fehler auf dem usb bus, zeigt aber kein Bild, über streamdev kommen noch Daten, aber nichts mehr was zu erkennen ist.) gleiches gilt für 2.6.38_rc3


    hab nun noch den 2.6.37 getestet. Problem bleibt, Klötzer und Fehlermeldung. Den patch von Seite 1 habe ich auch probiert (USB fix für 2.6.38, aber ohne Veränderung).
    NUn dachet ich schliesse ich wenigstens eine TT 3650 und eine Terratec Cinery USB DVB-S2 HD an ( die super läuft an meinem anderen Linux Rechner mit 2.6.37). Gleicher Treiberstand hier auf dem Asrock und es macht nur

    Code
    1. [ 302.406880] dw2102: i2c transfer failed.
    2. [ 302.406886] b0 00 00 00 00 00
    3. [ 304.406835] dvb-usb: bulk message failed: -110 (6/0)
    4. [ 304.406843] dw2102: i2c transfer failed.
    5. [ 304.406849] b0 1d 00 00 00 00
    6. [ 306.406792] dvb-usb: bulk message failed: -110 (6/0)
    7. [ 306.406800] dw2102: i2c transfer failed.
    8. [ 306.406806] b0 1d 1d 00 00 00
    9. [ 308.406754] dvb-usb: bulk message failed: -110 (6/0)
    10. [ 308.406762] dw2102: i2c transfer failed.


    Da die gleich Zusammenstellung auf einem anderen Rechner geht und mit 2.6.33 das Problem auch noch nicht auftrat, schliesse ich daraus, das irgendwas mit dem USB für den ION Chipsatz seit 2.6.34 "im Eimer" ist.


    Kann das jemand bestätigen, ob es nut ION's trifft oder auch andere Chipsätze ?


    Update:


    ich habe nochmal gesucht as der unterschied zwischen dem 2.6.33 und 34 ist und wie das zu den Änderungen zum Vanilla 32 mit dem 32-r25 unter gentoo passt. dabei ist in beiden Fällen folgender Patch mit eingeflossen


    beim nächsten Test werde ich diesen mal wieder rausnehmen, zumal ja hier in ISO Stream (also bei TT -36x0 Datenströmen, Mircroframes ausgelassen werden) Ich hoffe, das brint Änderungen.

    ja die sind (auch auf anderen Rechnern) mit dem Artefakten aufgenommen


    --
    so habs mal getestet mit 2.6.32 vanilla, leider selbes Ergebnis wie mir dem 2.6.38-rc3.(startet den vdr dann scheinen keine Daten mehr durchzukommen.) Muss ich wohl noch s2-liplianin in der Version testen, ab wann wieder ein bild kommt. Von daher kann ich noch keine genaue Aussage treffen mit einem nachträglichen downgrade auf 2.6.32.

    ja kann ich mal mit 2.6.32 vanllia testen.


    ich 2.6.27 hatte ich immer die "frischen vanilla sources". Bis einschliesslich 2.6.33 ging das immer gut, danach war kein Kernel mehr zu finden der das Problem behebt. Unter gentoo gibt es leider keinen ohne Patches mehr. Ich lade den mal von Hand.


    in dem Forum hatte ich auch schon mal gesucht, dort hatte jemand selbes beschrieben, das wurde dann aber (trotz Funktion unter Windows) auf einen defekten USB Kontroller geschoben (glaube ich mich zu erinnern). Ih suche mal den Thread.
    Hier ein Link auf meinen alten Breitrag mit Link zu dem Forum (mit Beispielbildern). Vielleicht kann ich morgen schon etwas zu, 2.6.32 sagen. Wenn ich einen Testrechner hätte könnte ich mit git bisect mal schauen wo genau das her kommt, nur haben ich nur den einen VDR laufen, und der wird fast durchgehend gebraucht ;)

    Quote

    Da jetzt Kernel 2.6.38-28-generic läuft warten wir also bis ein Kernelupdate zur Verfügung steht.


    du hast schon 2.6.38 drauf ?
    ist ja auch nur eine Idee, vielleicht liegt es auch nicht daran. Viel mehr fällt mir aber auch nicht ein dazu im Moment (ich suche da schon Monate nach dem Fehler)