Installation eines VDR+Plugins nativ auf CoreELEC Boxen

Zitat von Dr. Seltsam

Kannst Du mir helfen, diese Stelle zu identifizieren?

static void *VideoDisplayHandlerThread(void *dummy) {

    prctl(PR_SET_NAME, "video decoder", 0, 0, 0);
    sleep(2);
    pthread_cleanup_push(delete_decode, NULL);
    for (;;) {
        // fix dead-lock with CuvidExit
        pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
        pthread_testcancel();
        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

        VideoUsedModule->DisplayHandlerThread();
    }
    pthread_cleanup_pop(NULL);
    return dummy;
}

Das ist die Hauptschleife und nur da erkennt er den cancel. Wenn er da also nicht mehr durchkommt bleibt der cancel hängen.

Zitat von jojo61

Code

static void *VideoDisplayHandlerThread(void *dummy) {

    prctl(PR_SET_NAME, "video decoder", 0, 0, 0);
    sleep(2);
    pthread_cleanup_push(delete_decode, NULL);
    for (;;) {
        // fix dead-lock with CuvidExit
        pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
        pthread_testcancel();
        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

        VideoUsedModule->DisplayHandlerThread();
    }
    pthread_cleanup_pop(NULL);
    return dummy;
}

Alles anzeigen

Das ist die Hauptschleife und nur da erkennt er den cancel. Wenn er da also nicht mehr durchkommt bleibt der cancel hängen.

Das ist wahrscheinlich aus softhdcuvid? In softhdodroid sieht die Stelle so aus (mit meinen Debugmeldungen):

void *VideoDisplayHandlerThread(void *dummy)
{

  //  prctl(PR_SET_NAME, "video decoder", 0, 0, 0);
    Debug(2, "TEST: Beginn VideoDisplayHandlerThread()\n");
    pthread_cleanup_push(delete_decode, NULL);
    Debug(2, "TEST: VideoDisplayHandlerThread() pthread_cleanup_push abgeschlossen\n");
    for (;;) {
        // fix dead-lock with OdroidExit
        //Debug(2, "TEST: VideoDisplayHandlerThread() Beginn for-Schleife\n");
        pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
        //Debug(2, "TEST: VideoDisplayHandlerThread() pthread_setcancelstate enable abgeschlossen\n");
        pthread_testcancel();
        //Debug(2, "TEST: VideoDisplayHandlerThread() pthread_testcancel abgeschlossen\n");
        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
        //Debug(2, "TEST: VideoDisplayHandlerThread() pthread_setcancelstate disable abgeschlossen\n");
        OdroidDisplayHandlerThread();
        //Debug(2, "TEST: VideoDisplayHandlerThread() Aufruf OdroidDisplayHandlerThread abgeschlossen\n");
    }
    Debug(2, "TEST: VideoDisplayHandlerThread() for-Schleife beendet\n");
    pthread_cleanup_pop(NULL);
    Debug(2, "TEST: VideoDisplayHandlerThread() pthread_cleanup_pop abgeschlossen, es folgt return dummy\n");

    return dummy;
}

Ich habe jetzt erstmal mit Debug-Meldungen überprüft, ob und welche Zeilen im Code abgearbeitet werden, wenn in VideoExit auch VideoThreadExit ausgeführt wird. Es macht keinen Unterschied, ob die Umschaltung zu Kodi gelingt oder nicht - das Beenden der for-Schleife und der anschließende cleanup-pop und Verlassen der Funktion wird nie geloggt.

Erst bei Rückkehr von Kodi zu vdr wird der Aufruf der Funktion wieder geloggt. Auffällig ist, dass nur im Fehlerfall (hier: beim Wechsel zu Kodi kommt das vdr-Bild wieder zurück und überlagert sich mit dem Kodi-OSD) ein Aufruf von VideoDisplayHandlerThread auch beim Verlassen von vdr geloggt wird - was wohl damit zu tun hat, dass das vdr-Bild dann trotz Suspend ungewollt wiederkommt. Ab dem Zeitpunkt hat vdr dann eine neue PID (siehe 14:04:41 Uhr im anliegenden Logauszug)!

Bringt das neue Erkenntnisse?

Zitat

Du könntest aber in der Hauptschleife des VideoThread auch mal das deaktivieren des Cancel wegnehmen ob es dann besser klappt.

Welche Zeile genau soll ich deaktivieren?

Zitat von Dr. Seltsam

pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);

pthread_testcancel();

pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

Mit cancel_enable wird ein Cancel des Treads zugelassen und mit testcancel wird geprüft ob ein cancel ansteht. Wenn ja dann wird der Thread dort gecancelt und es gibt kein return. D.h. wenn er hier nicht durch kommt dann kann der Threaad nicht gecanceld werden weil er im Zustand cancel_disable für die eigentliche arbeit steht. Damit wird sichergestellt das er nur hier gecancelt werden kann. Dewegen wollte ich wissen ob er hier durchkommt (was er eigentlich mindestens einmal pro sekunde tun müsste). Wenn man die Zeile mit dem cancel_disable wegnimmt dann kann er wohl immer gecancelt werden egal wo er gerade im Ablauf ist.

Ich hatte mit meinem Odroid getestet ob ein deta hängen bleibt. Konnte es aber nicht reproduzieren.

Zitat von jojo61

mit testcancel wird geprüft ob ein cancel ansteht. Wenn ja dann wird der Thread dort gecancelt und es gibt kein return.

testcancel liefert leider nie einen return-Wert, egal ob ein cancel ansteht oder nicht. Deswegen wüsste ich jetzt nicht, wie ich in der Schleife loggen könnte, ob der Cancel-Befehl hier ankommt.

Zitat von jojo61

Ich hatte mit meinem Odroid getestet ob ein deta hängen bleibt. Konnte es aber nicht reproduzieren.

Auf dem N2 ist es auch schwieriger zu reproduzieren. Auf der Tanix TX3 tritt der Fehler bei einem von 5 bis 10 Versuchen auf. Ich habe das eben nochmal getestet. Ein abwechselndes svdrpsend plug softhdodroid DETA und svdrpsend plug softhdodroid ATTA reicht, um den Fehler relativ schnell zu reproduzieren. Man muss also gar nicht auf Kodi wechseln.

ok werde mal mit der X96 testen

Möglicherweise ist die Konstruktion in VideoThreadExit falsch:

    if (VideoThread) {
        void *retval;

        Debug(3, "video: video thread canceled\n");

        // FIXME: can't cancel locked
        if (pthread_cancel(VideoThread)) {
            Debug(3, "video: can't queue cancel video display thread\n");
        }
        usleep(200000);                 // 200ms
        if (pthread_join(VideoThread, &retval) || retval != PTHREAD_CANCELED) {
            Debug(3, "video: can't cancel video decoder thread\n");
        }


        VideoThread = 0;
    }

VideoThread wird unter Umständen auf 0 gesetzt, auch wenn das Ergebnis nicht PTHREAD_CANCELED ist. Das könnte dazu führen, dass VideoDisplayWakeup

    if (!VideoThread) {                 // start video thread, if needed
        VideoThreadInit();
    }

ausführt, falls es z.B. durch ein noch nicht verarbeitetes Paket (?) in VideoNextPacket getriggert wird.

VideoThreadInit erzeugt dann einen neuen VideoDisplayHandlerThread, was eine Erklärung dafür sein könnte, dass trotz Suspend der eigentlich schon gecancelte VideoDisplayHandlerThread wieder aufgerufen wird.

Der join sollte auf jeden Fall auf den exit des Thread warten.

Ich habe nun mal auf meinem X96 eine deta/atta orgie veranstaltet und es hat immer geklappt. D.h. der pthread_cancel hat immer einen erfolgreichen cancel abgesetzt und der join hat erfolgreich auf den exit gewartet.

Wie sieht das denn bei dir im Log aus wenn es nicht klappt.

Zitat von Dr. Seltsam

testcancel liefert leider nie einen return-Wert,

Stimmt. testcancel kommt zurück wenn kein Cancel ansteht und es kommt nicht zurück wenn ein cancel ansteht und der thread ist beendet.

Hast Du in chroot oder direkt in VDR*Elec getestet?

Das Problem ist, dass irgendwas noch vor vollständigem Abschluss des Suspend eine erneute Ausführung von VideoThreadInit triggert.

Zitat von Dr. Seltsam

Hast Du in chroot oder direkt in VDR*Elec getestet?

Ich habe in chroot getestet. Eine lauffähige VDR*Elec installation habe ich nicht.

Ich habe auch in chroot getestet. Du hast die aktuelle git-Version des Plugins benutzt?

Ich werde weiter debuggen…

Der Fehler ist manchmal schwierig zu reproduzieren. Es scheint auch vom OSD abhängig zu sein (hier: nopacity Dark Blue) und tritt anscheinend doch nur bei Wechsel zu Kodi (über Befehl in commands.conf; mein softoggle-Script enthält keine sleeps) auf.

Ich habe jetzt mehrfach Fehler im 20. Anlauf oder mehr nachgestellt.

Im Fehlerfall scheint in softhdodroid.cpp bei der Verarbeitung des DETA svdrp-Befehls etwas schief zu laufen. Im Erfolgsfall wird dort erst

cSoftOsdProvider::StopOpenGlThread() ausgeführt und danach Suspend(), ehe der Status auf SuspendMode = SUSPEND_DETACHED gesetzt wird.

Im Fehlerfall läuft der Suspend nicht durch, der SuspendMode wird nicht geändert und VideoDisplayWakeup ruft VideoThreadInit auf, weil VideoThread=false ist. Ich vermute, dass pthread_join nicht zum Ergebnis PTHREAD_CANCELED führt (warum auch immer) und die dennoch erfolgte Zuweisung VideoThread = 0 das Problem ist. Wodurch nun aber VideoDisplayWakeup ausgelöst wird, ist mir noch nicht klar.

Poste mal ein Log vom Fehlerfall.

Habe eine Detailfrage zum vdr-plugin-markad(ng).

Wie wird es bei VDRSternELEC aufgerufen? Über welches Script?

Denn offenbar werden die gesetzten Settingsvariablen nicht dahin übernommen -> Details

VDRSternELEC/packages/vdr/_vdr-plugin-markad at master · Zabrimus/VDRSternELEC

Contribute to Zabrimus/VDRSternELEC development by creating an account on GitHub.

github.com

Das Plugin muss in enabled_plugins drin stehen, damit es gestartert wird.

Die conf Datei für das Plugin liegt wie alle anderen conf in /storage/.config/vdropt/conf.d

Das standalone Programm markad wird standardmäßig überhaupt nicht aufgerufen. Es ist in keinem Skript z.B. aus reccmds.conf oder wird über ein Skript über die -r option aufgerufen. Das wäre selbst zu machen.

Auf meinem Server rufe ich das markad bin z.B. nach Ende der Aufnahme auf. Das Plugin nutze ich gar nicht.

Zitat von kfb77

sondern von dir per direkten Aufruf oder per Skipt

Das deckt sich mit meiner Aussage. Mit "dir" warst du selbst gemeint, nicht die Distribution.

Aha, ich habe das Plugin enabled. Also starte es hier automatisch.

Genauer: Es startet markad mit den Settings aus /storage/.config/vdropt/conf.d automatisch.

Und benutzt dabei ebenso gesetzte Parameter (OSD) vom Plugins.

Das war ein Verständnisproblem bei mir, weil ich dachte eine Aufrufoption fehlt...

Also alles ok.

Mein Problem mit dem Plugin wird im markad Thema weiter diskutiert.

So, Heute habe ich meine Installation upgedatet - jetzt wird allerdings keine dvb Hardware mehr gefunden.

Baue in einer Ubuntu vm selber. Also im VDRSternELEC Pfad ein git pull ausgeführt und danach./build.sh -config CoreELEC-20-ng -extra dynamite,channellogos -addon dvb-latest,dvb-tools,network-tools,system-tools abgeschickt.

Das erstellte Image (CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20240205204629-Odroid_N2L.img.gz) auf den Odroid N2+ in .update kopiert und neu gestartet.

Update ist durchgelaufen. Aber nach Neustart kommt Kanal nicht verfügbar.

vdr2:~ #  journalctl | grep dvb
Feb 06 21:04:02 CoreELEC kernel-overlays-setup: processing conf /storage/.cache/kernel-overlays/50-driver.dvb.dvb-latest.conf
Feb 06 21:04:02 CoreELEC kernel-overlays-setup: added modules from /storage/.kodi/addons/driver.dvb.dvb-latest//kernel-overlay/lib/modules/4.9.269
Feb 06 21:04:03 vdr2 systemd[1]: Starting amlogic-dvb.service...
Feb 06 21:04:04 vdr2 systemd[1]: amlogic-dvb.service: Deactivated successfully.
Feb 06 21:04:04 vdr2 systemd[1]: Finished amlogic-dvb.service.
Feb 06 21:04:12 vdr2 vdr[3668]: [3671] dynamite udev monitor for subsystem dvb thread started (pid=3668, tid=3671, prio=high)
Feb 06 21:04:13 vdr2 vdr[3668]: [3668] udev: no devices found for dvb/DVB_DEVICE_TYPE=frontend
Feb 06 21:04:14 vdr2 kernel: vfm_map_store:add dvblpath dvbldec amvideo

WinTV dualHD Tuner ist angeschlossen:

vdr2:~ # lsusb
...
Bus 001 Device 004: ID 2040:8265 Hauppauge dualHD

vdr2:~ #  journalctl | grep dual
Feb 06 21:04:02 CoreELEC kernel: usb 1-1.2: Product: dualHD
Feb 06 21:10:45 vdr2 kernel: usb 1-1.2: Product: dualHD

Liegt es am dynamite oder vtuner Integration? Oder?

Nein, ich nutze nur einen lokalen USB Tuner (WinTV dualHD).

Mein letztes (lauffähiges) Update ist vom 01.02. - d.h. es lief vdr 2.6.6 und dynamite schon bei mir.

Hatte gestern auch den build Unterordner gelöscht und nochmal komplett neu bauen lassen. Mit dem gleichen Ergebnis.

Und DVB Treiber kommen ja von CoreELEC. Hatte dort extra nochmal dvb-latest aus Repository aktualisiert. Ohne Erfolg.

Oh, das N2L ist ein copy&paste Fehler von mir habe schon das richtige N2 Image verwendet.

Schaue mir das heute Abend nochmal weiter im Detail an. Probiere dann mal ohne dynamite zu bauen...