Beiträge von seahawk1986

    Ich habe die Zeile 100 ff. in der player.c mal noch um eine Address-Angabe für den Pointer c erweitert:

    Code: player.c
    1. void cControl::Shutdown(void)
    2. { printf("calling cControl::Shutdown() player.c:101\n");
    3. cMutexLock MutexLock(&mutex); printf("created cMutexLock in cControl::Shutdown() player.c:102\n");
    4. cControl *c = control; /* avoids recursions */ printf("creating cControl *c in cControl::Shutdown() player.c:103\n");
    5. control = NULL; printf("setting control = NULL in cControl::Shutdown() player.c:104\n");
    6. printf("Address of c is %p\n", (void *)c); delete c; printf("leaving cControl::Shutdown() player.c:105\n");
    7. }

    Das sieht dann z.B. so aus:

    Code
    1. calling cControl::Shutdown() player.c:101
    2. created cMutexLock in cControl::Shutdown() player.c:102
    3. creating cControl *c in cControl::Shutdown() player.c:103
    4. setting control = NULL in cControl::Shutdown() player.c:104
    5. Address of c is 0x959598

    Wenn ich mich dann mit gdb an den hängenden VDR-Prozess attache, bekomme ich für das cControl-Objekt:

    Code
    1. gdb ./vdr $(pidof vdr)
    2. [...]p
    3. (gdb) p *(cControl *) 0x959598
    4. $2 = {<cOsdObject> = {_vptr.cOsdObject = 0x631cc0 <vtable for cTransferControl+8>, isMenu = false, needsFastResponse = false}, static control = 0x0, static mutex = {mutex = {__data = {__lock = 1, __count = 0, __owner = 11773,
    5. __kind = 2, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000\375-\000\000\002\000\000\000\001\000\000\000\000\000\000", __align = 1}, locked = 1}, attached = true,
    6. hidden = true, player = 0x9596e8}

    Hält das da selbst noch einen Mutex?

    In der vdr.c kommt er bis Zeile 1412, das ist der Aufruf von cControl::Shutdown(). In der player.c kommt er bis Zeile 105:

    Code: player.c
    1. void cControl::Shutdown(void)
    2. { printf("calling cControl::Shutdown() player.c:101\n");
    3. cMutexLock MutexLock(&mutex); printf("created cMutexLock in cControl::Shutdown() player.c:102\n");
    4. cControl *c = control; /* avoids recursions */ printf("created cControl *c in cControl::Shutdown() player.c:103\n");
    5. control = NULL; printf("set control = NULL in cControl::Shutdown() player.c:104\n");
    6. delete c; printf("leaving cControl::Shutdown() player.c:105\n");
    7. }

    Auf stdout sieht man dann beim Abspielen einer Aufnahme vor dem Hänger:

    Code
    1. calling cControl::Shutdown() player.c:101
    2. created cMutexLock in cControl::Shutdown() player.c:102
    3. created cControl *c in cControl::Shutdown() player.c:103
    4. set control = NULL in cControl::Shutdown() player.c:104

    Also hängt er in Zeile 105 bei delete c;. Wenn ich das entferne (also im Original Zeile 105 auskommentiere), gibt es keinen Hänger mehr und die Aufnahme wird abgespielt - verstehe ich das richtig, dass damit nicht der Pointer selbst, sondern der Speicherbereich gelöscht werden soll, auf den er zeigt?

    Hatte vdr nicht irgendwann mal dieses sd_notify implementiert und service-Type notify müsste funktionieren? Dies ging bei mir aber nicht.

    Das musst du extra einschalten - also den VDR mit SDNOTIFY = 1 in der Make.config bauen und dann noch in der Unit Type=notify setzen.


    Beim umschalten sehe ich im Hintergrund nun den Curser von tty7, verräts du mir noch wie du den weg bekommen hast

    Probiers mal über setterm:

    ExecStartPre=-/bin/bash -c '/usr/bin/setterm --blink off --clear all --cursor off > /dev/tty7'

    Hast du ps mit root-Rechten aufgerufen, damit es die Info anzeigen kann? Auf meinem Raspberry Pi sieht das unter Arch Linux ARM so aus:

    Code
    1. $ sudo ps ww $(pidof vdr)
    2. PID TTY STAT TIME COMMAND
    3. 376 tty7 Ssl+ 0:02 /usr/bin/vdr

    Der VDR braucht in der remote.conf dann keine XKeySym.* Einträge, sondern welche mit KBD.* - ggf. mal die remote.conf leeren und die Tastatur neu anlernen.

    Außerdem darf der VDR natürlich nicht mit der Option --no-kbd gestartet worden sein - das kannst du mit vdr --showargs prüfen.

    Leider ist die readme zum rpihddevice sehr dürftig zu diesem Thema.

    Das hat ja auch nichts mit der Weiterleitung der Tastendrücke zu tun.

    Hat jemand noch einen Tipp wie ich das mit service file und stdin anstellen kann.

    Für Details kannst du einen Blick in die Dokumentation zu Systemd werfen: https://www.freedesktop.org/so….exec.html#StandardInput= ff.

    Auf meinem Raspberry Pi 2 ist das dann z.B. so ein Drop-In für die vdr.service:

    Code
    1. [Unit]
    2. Conflicts=getty@tty7.service
    3. [Service]
    4. StandardInput=tty-force
    5. StandardOutput=syslog
    6. TTYPath=/dev/tty7
    7. TTYReset=no
    8. TTYVHangup=yes
    9. ExecStartPre=/usr/bin/chvt 7

    Hallo,

    ich habe den VDR 2.3.9 auf einem Raspberry Pi 2 unter Arch Linux ARM ausprobiert - LiveTV über das streamdev-client Plugin funktioniert, aber bei der Wiedergabe von Aufnahmen (egal ob von der SD-Karte oder über NFS) hängt sich der VDR weg.

    Im Log sieht man nur, dass ein i/o throttle aktiv wird und der Buffer voll läuft. Der VDR ist dann unbedienbar, bis der Watchdoch zuschlägt. Neben dem streamdev-client ist nur das rpihddevice-Plugin aktiv. Der VDR wurde zur Ursachenforschung ohne Patches gebaut.

    Laut htop hat die CPU währenddessen kaum etwas zu tun.


    Ich hatte versuchsweise #define USE_FADVISE_READ = 1 in die tools.c eingebaut, das hat nichts am Verhalten geändert. Mit dem VDR 2.3.8 hatte ich das Problem noch nicht. Auf dem Testrechner für Ubuntu 18.04 und VDR 2.3.9 klappt die Wiedergabe von Aufnahmen mit softhddevice über VDPAU.


    Wie kann man dem Problem am besten auf die Spur kommen?

    Verschachtelte read-Loops sind etwas tricky... - da muss man pro read einen eigenen File-Descriptor nutzen - also z.B.:

    Du musst über die Paketverwaltung gehen und das entsprechende nvidia-* Paket installieren. dkms baut dann automatisch die Kernel-Module. cuda brauchst du für VDPAU nicht.


    Ich würde das Kernel-Update ohne tatsächlichen Bedarf dafür (z.B. wenn du weißt, dass der neue Kernel bestimmte Probleme im Zusammenhang mit deiner Hardware behebt) nicht unbedingt machen. IIRC ist das media-build-experimental-dkms Paket nicht für den Kernel 4.4 angepasst und das PAket yavdr-essential muss reinstalliert werden, nachdem man den neuen Kernel und xorg-Stack eingespielt hat.

    ubuntu-toolchain-r

    Das dürfte die Ursache für deine Probleme sein - das bringt dir u.a. eine neuere gcc-Version (die aber dummerweise den retpotline-Fix nicht beinhaltet) - das PPA wird auch im oben verlinkten Bugreport als mögliche Ursache genannt.


    Mir ist nicht klar, warum man für das kodi stable PPA (https://launchpad.net/~team-xbmc/+archive/ubuntu/ppa) eine andere gcc-Version braucht - immerhin habe ich die Pakete daraus in die yaVDR-PPAs übernommen, ohne die gcc-Version ändern zu müssen.

    Habe ich beides gemacht und finde kein "retpotline" in der vermagic-Zeile.

    Muss ich nach remove/install neu booten? Hab ich jetzt nämlich nicht.

    Wäre sinnvoll, damit das neue Treibermodul geladen wird. Auf meinem yaVDR 0.6.1 sieht das aktuell so aus: