Posts by UFO

    Das Anwachsen des Speichers hat afaics nichts mit der Wiedergabe zu tun.


    Es passiert auch im Live-Modus, wenn keine Aufnahmen laufen.
    Falls es tatsächlich im vdr-Core wäre, kommen in Anbetracht des Anwachsens des Speicherverbrauchs eigentlich nur EPG-Verarbeitung oder Channel-Scan in Frage.



    CU
    Oliver


    P.S.
    Leider funktionieren alle Memory-Checker, die ich probiert habe, mit VDR ziemlich schlecht. Das mehrfache fork() bringt da so einiges durcheinander.

    Ich sehe den Speicherfresser bei 2 Geräten:
    - Banana Pi mit softhddevice + vdpau (32-Bit-System ARM)
    - TT-S2-6400 auf Intel 64-Bit-System


    Den Banana-Pi möchte ich außen vor lassen, denn vdpau dort ist ein ziemliches Gebastel. Mich würde nicht wundern, wenn in gewissen Fällen Puffer verloren gehen könnten. Eine Abfrage von Return-Codes bei ioctls scheint dort die Ausnahme zu sein. ;(


    Auf dem 64-Bit 6400er-System scheint der Speicherverbrauch allerdings ebenso keine Grenzen zu kennen. Mittlerweile bin ich bei 417 MB RES angekommen, und er steigt weiter. An Plugins laufen z.Zt. nur dvbhddevice und remote.


    Bleibt die Frage:
    Wie kann es sein, dass der Speicherbedarf bei einem 32-Bit System mit TT S2-6400 konstant bleibt und bei 64-Bit über alle Grenzen wächst? Wenn man nicht irgendwelche Pointer-Manipulationen macht, sollte so etwas doch gar nicht möglich sein? Vorausgesetzt, es gibt kein Leak in irgendwelchen 64-Bit-Libraries.


    CU
    Oliver

    Wenn das Gerät sehr heiß wird, könnte dies auch durch einen Kurzschluß in einem Kabel/Stecker oder im Multischalter verursacht werden.


    Die Fehlerbeschreibung oben ist unklar:
    Ist immer Tuner 3 betroffen oder wandert der Fehler, wenn man die Kabel von Tuner 3 und 4 - am Octopus Net (!!!) - vertauscht? Falls der Fehler wandert, liegt es definitiv nicht am Octopus Net.


    CU
    Oliver

    AFAICS hat der bestehende cTsToPes::GetPes() Code ein Problem, falls
    - repeatLast == true und
    - Speicherblock bei realloc() verschoben wird
    Dann zeigt lastData auf einen ungültigen Speicherblock.


    Edit:
    Derartige Probleme könnte man vermeiden, wenn man nicht den Pointer, sondern den Offset im Puffer speichern würde.
    Aber ehrlich gesagt, verstehe ich den GetPes()-Code noch nicht so recht...


    Edit2:
    Steht allerdings auch im Kommentar:
    "The returned pointer is only valid until the next call to PutTs() or Reset(), or until this object is destroyed."


    CU
    Oliver

    Hier werden Frontends angelegt:

    Code
    1. ...
    2. [ 7.893215] usb 1-3: DVB: registering adapter 8 frontend 0 (Realtek RTL2832 (DVB-T))...
    3. ...
    4. [ 8.117603] usb 1-4: DVB: registering adapter 9 frontend 0 (Realtek RTL2832 (DVB-T))...
    5. ...


    Dies fehlt mit dem neuen Treiberpaket.


    Wie gesagt, zu 99,9% ein Fehler im Upstream media-build.


    CU
    Oliver


    P.S.:
    Falls jemand einen Patch liefern kann, der das Problem behebt, werde ich diesen ins patch.d-Verzeichnis übernehmen. Ansonsten müssen wir auf einen Bugfix im Upstream-Treiber warten.

    Ich sehe im Log nichts Aufschlussreiches. Es wird kein Frontend geladen.


    Ob die Erkennung als "Realtek RTL2832U reference design" korrekt ist, kann ich nicht sagen. Evtl. mit einem alten Log vergleichen. Ich meide DVB-USB-Devices wie die Pest.


    Quote


    Ich habe es gerade nochmal mit dem aktuellen Commit unter kernel-3.19.0 getestet, da tritt der o.g. Fehler auch auf. Mit "changeset 462:6f71c74a5afc" und kernel-3.19.0 ist noch alles OK.


    Dies verwendet einen älteren Treiberstand von media_build, der aber nicht nicht mit Kernel 4.x baut - sonst hätte ich nicht aktualisiert.


    Um zu verifizieren, dass es definitiv am Upstream-Treiber liegt:
    - media_build_experimental aus /lib/modules/... deinstallieren.
    - media_build aus http://git.linuxtv.org/cgit.cgi/media_build.git installieren.
    - Test wiederholen.


    Falls das Problem nach wie vor auftritt - wovon ich ausgehe - Bugreport auf der linux-media Mailing-Liste absetzen.


    CU
    Oliver

    Leider lässt sich damit das rtl28xxu Modul nicht bauen. :(
    ...


    Läuft hier problemlos durch (Kernel 4.0.2 von kernel.org).
    War das ein frischer Checkout?


    Beinem alten Checkout evtl. irgendein Schritt vergessen?
    - hg pull -u
    - make distclean
    - make download
    - make untar
    - make



    und da ist jetzt auch der richtige dddvb-0.9.18 drin und nicht mehr der beta3? - Dann wäre das jetzt der richtige Zeitpunkt für ein neues media_build_experimental dkms in ya.


    Nur wenn Beta drauf steht, ist auch Beta drin. :D


    Aus CHANGELOG:

    Code
    1. 0.9.18 2015.05.05
    2. - support GT links
    3. - fixes for mxl5xx tuning
    4. (prevent simultaneous tuning inside 100ms)
    5. - allow dynamic fmode change
    6. ...

    Es kann erst dann einen Update geben, wenn der Upstream-Treiber wieder brauchbar ist.
    Seit Tagen ist media_build praktisch nicht mehr kompilierbar:


    Ich glaube nicht, dass jemand solche Treiber haben möchte...

    Vermutlich ist hier der Hund begraben...

    Code
    1. KbdFactory: successfully loaded: nn.pp.rckbd.KeyTranslator
    2. KbdFactory: java.lang.ClassNotFoundException: nn.pp.rckbd.KeyTranslator_en
    3. KbdFactory: java.lang.ClassNotFoundException: nn.pp.rckbd.KeyTranslator_en_US
    4. KbdFactory: java.lang.ClassNotFoundException: nn.pp.rckbd.KeyTranslator104pc
    5. KbdFactory: java.lang.ClassNotFoundException: nn.pp.rckbd.KeyTranslator104pc_en
    6. KbdFactory: java.lang.ClassNotFoundException: nn.pp.rckbd.KeyTranslator104pc_en_US
    7. KbdFactory: successfully loaded: nn.pp.rckbd.KbdLayout_pc104


    ... und es wird das falsche Layout geladen. Hast Du eine US-Tastatur?


    CU
    Oliver

    Per Zufall habe ich beim umstecken der KArte den Stomstecker vergessen, seit dem scheint die Karte stabiler zu laufen. Eher seltsam, denn in den ganzen Foren steht es so das die Karte ohne den Stromstecker gar nicht geht...


    Wenn das irgendwo steht, ist es falsch. Die Karte selbst braucht nur in Ausnahmefällen die Zusatzspannungsversorgung. Bei der DuoFlex-Erweiterung dagegen muß sie immer angeschlossen werden.


    Quote

    Die andere Beobachtung ist das die Karte nach einem Neustart immer funktioniert, dazu muss ich es nicht mal für eine Minute vom Netz trennen. Da mein System sonst per Autoshutdown in den Standby geht vermute ich mal das der Treiber oder sonst irgendwas nicht mit dem Standby zurechtkommt. Wo fange ich da am besten mit der suche an?


    Von Standby war bisher nie die Rede! Die Treiber funktionieren nicht über Standby hinweg, sondern müssen vorher entladen und danach neu geladen werden.

    Hallo,


    es gibt eine neue Version des Remote Control Plugins.


    Download: http://www.escape-edv.de/endriss/vdr/vdr-remote-0.6.0.tgz



    History:
    --------
    2015-04-12: Version 0.6.0
    - Use Repeat Delay/Repeat Delta settings (VDR->Setup->Miscellaneous).
    - Support event type 2 (mouse wheel, rotary-encoder) as a remote control
    (thanks to Thomas Reufer).
    - Improved OSD emulation:
    o Reworked tabulator processing.
    o Optimal use of limited screen width.
    o Avoid display errors with VDR 2.2.0.
    o Fixed misaligned output caused by multi-byte characters.
    o Some speed improvements.



    See README for details.



    Short description:
    ------------------
    This plugin extends the remote control capabilities of vdr.
    The following remote control devices are supported:


    (a) linux input device driver ('/dev/input/eventX', X=0,1,2,...)
    - Built-in remote control port of the TT DVB-S2 6400
    (HD full-featured card).
    - Built-in remote control port of the av711x-based DVB cards
    (SD full-featured cards), e.g. DVB-S Nexus.
    - Remote control port of some budget cards, e.g. Nova-CI.
    - Other input devices (rotary-encoder, wheel mouse).
    See file FAQ for a list of cards which have been reported to work.


    (b) keyboard (tty driver): /dev/console, /dev/ttyX


    (c) TCP connection (telnet)


    (d) LIRC



    CU
    Oliver