Video Treiber für Odroid-N2+ (softhdodroid)

Hier ist der BT:

Edit: Vielleicht muss ich noch dazu sagen, dass der DVB-Empfänger noch nicht funktioniert. Evtl will er ein Video abspielen und hat keines?

Starting program: /usr/local/bin/vdr -v /video -c /var/lib/vdr -Psofthdodroid\ -a\ hw:CARD=AMLAUGESOUND,DEV=1\ -r50\ -g3840x2160

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

[New Thread 0x7fecb13170 (LWP 1033)]

[New Thread 0x7fe7fff170 (LWP 1034)]

[Thread 0x7fe7fff170 (LWP 1034) exited]

[New Thread 0x7fe7fff170 (LWP 1038)]

[New Thread 0x7fe695b170 (LWP 1039)]

FindDevice: open /dev/dri/card0: meson

Connector >HDMI-A-1< is not connected

Requested Connector not found or not connected

Thread 1 "vdr" received signal SIGABRT, Aborted.

__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt

#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

#1 0x0000007ff79e9aac in __GI_abort () at abort.c:79

#2 0x0000007ff57f9cfc in VideoInit (i=<optimized out>) at video.c:1827

#3 0x0000007ff57fd150 in StartVideo () at softhddev.c:2974

#4 Start () at softhddev.c:2974

#5 0x0000007ff57e5b90 in cPluginSoftHdDevice::Start() (this=<optimized out>) at softhdodroid.cpp:2880

#6 0x000000555567127c in cPluginManager::StartPlugins() (this=<optimized out>) at plugin.c:384

#7 0x00000055555eb52c in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at vdr.c:868

Ja, einen Denon Receiver. Mit der alten Version funktioniert es aber problemlos (Kernel 4.9).

Das kann ich aber nicht heute machen, da mein WAF dann sinkt

Zitat von beta

Das Umschalten funktioniert bei mit aus der commands.conf heraus (externalplayer Crash immer noch).

Welcher Umschaltvorgang crasht bei Verwendung des externalplayer-Plugins?

von vdr zu kodi -> kodi crasht

oder

von kodi zurück zu vdr -> vdr crasht

?

Wie sieht Dein Eintrag in der commands.conf aus bzw. des darin aufgerufenen Scripts? Wahrscheinlich killst Du da auch nur den looper. Über softoggle wird dann das Plugin per sdvdrp detached. Dabei wird im softhdodroid-Plugin intern SuspendMode=SUSPEND_DETACHED gesetzt.

    if (!strcasecmp(command, "DETA")) {
        if (SuspendMode == SUSPEND_DETACHED) {
            return "SoftHdDevice already detached";
        }
        if (cSoftHdControl::Player) {   // already suspended
            return "can't suspend SoftHdDevice already suspended";
        }

        dsyslog("[softhddev]stopping Ogl Thread svdrp DETA");
        cSoftOsdProvider::StopOpenGlThread();
        cControl::Launch(new cSoftHdControl);
        cControl::Attach();
        Suspend(1, 1, 0);
        SuspendMode = SUSPEND_DETACHED;

Wenn das externalplayer-Plugin verwandt wird, findet beim Aufruf ein Playmode-Wechsel zu pmExtern_THIS_SHOULD_BE_AVOIDED statt. Das löst nun einen Suspend aus, diesmal mit Status SUSPEND_EXTERNAL.

        case pmExtern_THIS_SHOULD_BE_AVOIDED:
            dsyslog("[softhddev] play mode external\n");
            // FIXME: what if already suspended?
            Setup.CurrentVolume = cDevice::CurrentVolume();
            Setup.Save();
            Suspend(1, 1, 0);
            SuspendMode = SUSPEND_EXTERNAL;

            dsyslog("[softhddev]stopping Ogl Thread pmExtern_THIS_SHOULD_BE_AVOIDED");
            cSoftOsdProvider::StopOpenGlThread();

Danach (?) wird wie in der externalplayer.conf festgelegt der looper gekillt. Das löst nun nochmal den gleichen Weg wie zuvor beschrieben aus. Eigentlich kann da nichts passieren - wenn bereits suspended ist oder der OpenGlThread gestoppt ist, wird das erkannt und nichts weiter ausgeführt.

Bei der Rückkehr von kodi zu vdr bin ich nun überfragt, ob/wie vdr den Playmode-Wechsel (Beenden von pmExtern_THIS_SHOULD_BE_AVOIDED) da mitkriegt oder ob ausschließlich das Attachen über softoggle das vdr-Bild zurückbringt.

Lange Rede, kurzer Sinn: Ich sehe zwar Unterschiede in der Ablaufsteuerung bei den beiden Methoden, aber noch keinen Ansatz wo es knallen könnte...

Hallo Dr. Seltsam und frohe Weihnachten. Es knallt bei VDR->KODI (Kodi Crash) mit dem Externalplayer. Commands.conf funktioniert. Beide killen eigentlich nur den looper, und unter 4.9 funktioniert das auch. Leider habe ich die Sourcen des Kernels nicht, so dass ich an dieser Stelle nicht Debugger kann. Ich habe ja auch noch das Problem, dass VDR Crash, wenn der TV nicht beim Booten an ist (ich arbeite hier gerade an einem Skript, das Softhdodroid in dem Fall suspended startet und erst attached, wenn der TV an ist.

jojo61 Jetzt, wo die TBS5580 läuft, ist mir ein weiteres Problem aufgefallen. Nach Rückkehr von KODI zu VDR funktioniert Dolby Digital nicht mehr. Statt eines vernünftigen Tons kommt nur ein Geknatter. Nach einem Reboot funktioniert es wieder, so lange, bis man zu KODI wechselt und zurück.

Das mit dem Crash bei ausgeschaltetem TV ist echt nervig, da VDR dann munter coredumps schreibt und zwar so lange, bis das filesystem voll ist.

Sonst läuft es rund und flüssig.

In der softoggle hast Du ja gem. Installationsscript beim Attachen noch einen Plugin-Parameter für die Audioptionen:

$PFAD/svdrpsend.sh PLUG softhdodroid ATTA -a hw:CARD=AMLAUGESOUND,DEV=2

Zum einen bin ich mir nicht sicher, ob über svdrp neben dem sdvrp-Kommando überhaupt Pluginparameter gesetzt werden können. Falls ja: Ist DEV=2 noch richtig? Wird hier evtl. auch noch ein Parameterientrag für -p benötigt?

Zu dem Problem des kodi-crash bei Nutzung des externalplayer-Plugins:

Probier doch mal, in der softoggle vor dem Aufruf von systemctl start kodi einen sleep einzubauen. Vielleicht ist die Hardware an der Stelle noch damit beschäftigt, die DETA-Befehle des Plugins zu verarbeiten. Jetzt wirst Du vielleicht sagen, das müsste dann aber auch beim Befehl über die commands.conf passieren. Eventuell wird da aber beim externalplayer im softhdodroid-Plugin doch etwas doppelt gemacht (erst durch den Playmodewechsel, dann durch nochmaliges Detachen).

Die Parameter spielen keine Rolle. Das Verhalten scheint zufällig zu sein: Mal gibt es nach Rückkehr von KODI zu VDR DD-Ton, mal nicht. Wenn ich dann ein paar Mal das Plugin DETA und wieder ATTA, dann geht es irgendwann wieder. Irgendwas scheint mit der Initialisierung von DD-Audio von DETA -> ATTA nicht mehr zu funktionieren mit dem 5-Kernel.

2. Problem: VDR -> KODI und zurück. Das ist abhängig vom Skin, der in Skindesigner eingestellt ist, ob es funktioniert oder ob nicht. Hier scheint irgendeine OpenGL-Ressource noch nicht richtig freigegeben zu werden. Nehme ich die KODI libMali.so für softhdodroid, funktioniert der Wechsel z.B. mit shady_kiss. Nehme ich ich r12 aus dem CoreElec Repro, geht das nicht. Dafür geht es mit der CE libMali nicht bei anderen Skins.

Edit: Was mir noch auffällt: Wenn der Wechsel VDR->KODI ohne crash KODI funktioniert, ist für kurze Zeit ein Teil des OSDs sehr groß auf dem Bildschirm zu sehen. Erscheint das nicht, crasht KODI bei mir.

Zitat von jojo61

Warum geht ihr denn mit dem 5.15.x Kernel produktiv. Das ist doch eh noch alles BETA.

eher Alpha ...

Ich nutze es ja noch gar nicht produktiv, ich möchte nur ein wenig basteln.

Der Tipp mit dem KODI zu früh starten war Gold wert. Mit einem kleinen sleep funktioniert es, auch per externalplayer, egal mit welcher libMali.

Ich schaue mir das mit dem Audio-Device mal selbst an. Vielleicht finde ich ja etwas.

Zitat von beta

Der Tipp mit dem KODI zu früh starten war Gold wert. Mit einem kleinen sleep funktioniert es, auch per externalplayer, egal mit welcher libMali.

an welcher Stelle hast Du wieviel sleep eingebaut?

Auf einer Tanix TX3 habe ich kurioserweise unter Kernel 4.9 Probleme mit dem Umschalten über die commands.conf - da kriege ich es nur mit dem externalplayer-Plugin hin.

Hinter dem DETA habe ich ein sleep von 3s eingebaut.

Ich habe das Umschalten zwischen vdr und kodi mittels des softoggle-Scriptes nochmal genauer analysiert, indem ich diverse Debug-Meldungen im Script und im Plugin verstreut habe.

Beim Aufruf über das externalplayer-Plugin erfolgt aufgrund dessen Playmode pmExtern_THIS_SHOULD_BE_AVOIDED zunächst ein Suspend mit SuspendMode SUSPEND_EXTERNAL. Danach erfolgt ein Resume aufgrund dieser Konstruktion in softhdodroid.cpp`s SetPlayMode:

     if (SuspendMode != NOT_SUSPENDED) {
        if (SuspendMode != SUSPEND_EXTERNAL) {
            return false;
        }
        Resume();
        SuspendMode = NOT_SUSPENDED;
    }

Da der Playmode SUSPEND_EXTERNAL ist, führt das an dieser Stelle nach dem gerade durchgeführten Suspend also wieder zu einem Resume. Zudem kommt es -warum auch immer- mittlerweile zu einem Wechsel auf Playmode 1, was in softhddev.c den Aufruf vpn Play() auslöst, was wiederum ein amlResume auslöst.

Danach wird aufgrund von softoggle über die svdrp-Schnittstelle ein DETA ausgelöst, diesmal mit SuspendMode SUSPEND_DETACHED

Also im Ergebnis Suspend -> Resume ->Suspend statt nur 1x Suspend!

Es macht sicher Sinn, in der softoggle vor dem Starten von kodi einen sleep einzubauen, denn die Abarbeitung der ganzen Treiberbefehle beim Suspend dauert - je nach Hardware ein paar Sekunden mehr. Ideal wäre es aber, wenn wir in der softoggle den exakten Zeitpunkt, wo das OSD gelöscht ist, checken könnten.Das ist leider nicht ganz einfach, denn die Werte in /sys/class/... zwischen laufendem vdr und nach erfolgtem Suspend (VideoExit abgeschlossen) unterscheiden sich z.T. nicht. Aus VideoExit:

    amlSetInt("/sys/class/graphics/fb0/free_scale", 0);
    // restore vfm mapping
    if (myKernel == 4) {
        amlSetInt("/sys/class/graphics/fb0/free_scale", 0);
        amlSetString("/sys/class/vfm/map","rm pip0");   // make it save
        amlSetString("/sys/class/vfm/map","rm all");
        sleep(1);
        amlSetString("/sys/class/vfm/map","add default decoder amvideo");
        amlSetString("/sys/class/vfm/map","add default_amlvideo2 vdin1 amlvideo2.1");
        amlSetString("/sys/class/vfm/map","add dvblpath dvbldec amvideo");
        amlSetString("/sys/class/vfm/map","add dvelpath dveldec dvel");
        amlSetString("/sys/class/vfm/map","add dvhdmiin dv_vdin amvideo");
        amlSetString("/sys/class/amvecm/debug","3dlut close");
        amlSetString("/sys/class/amvecm/debug","3dlut disable");
    } else {
        amlSetInt("/sys/class/graphics/fb0/free_scale", 0);
        amlSetString("/sys/class/vfm/map","rm pip0");   // make it save
        amlSetString("/sys/class/vfm/map","rm all");
        sleep(1);
        amlSetString("/sys/class/vfm/map","add default decoder amvideo");
        amlSetString("/sys/class/vfm/map","add default_amlvideo2 vdin1 amlvideo2.1");
        amlSetString("/sys/class/vfm/map","add dvblpath dvbldec amlvideo ppmgr deinterlace amvideo");
        amlSetString("/sys/class/vfm/map","add dvelpath dveldec dvel");
        amlSetString("/sys/class/vfm/map","add dvblpath2 dvbldec2 videopip");
        amlSetString("/sys/class/vfm/map","add dvelpath2 dveldec2 dvel");
        amlSetString("/sys/class/vfm/map","add dvhdmiin dv_vdin amvideo");
        amlSetString("/sys/class/vfm/map","add video-map-0 video1_block amvideo");
        amlSetString("/sys/class/vfm/map","add video-map-1 video2_block videopip");
    }
    // reset audio codec to 2 chan
    amlSetInt("/sys/class/audiodsp/digital_codec", 0);
    
    amlSetString("/sys/class/video/crop", "0 0 0 0");

    if (myKernel == 4) {    
        amlSetInt("/sys/class/graphics/fb0/blank", 0);
    } else {
        amlSetInt("/sys/class/graphics/fb0/blank", 0);
    }

Der Aufruf von amlSetInt("/sys/class/graphics/fb0/free_scale", 0); erscheint mir hier doppelt, da unabhängig von der Kernelversion bereits eingangs ausgeführt. Und der letzte Teil (amlSetInt("/sys/class/graphics/fb0/blank", 0);)braucht doch nicht kernelabhängig sein, wenn eh gleich?

Der einzige Wert, der nach erfolgtem Suspend anders ist, ist /sys/class/graphics/fb0/free_scale. Die cat-Ausgabe ändert sich von free_scale_enable:[0x10001] auf free_scale_enable:[0x0]. Aber ich wüsste nicht, wie man ermitteln kann, ob das ganze danach noch stattfindende mapping durch ist.

So wie es jetzt ist, dauert der Wechsel unnötig lange - auf meinem N2 fast 10 Sekunden zwischen OSD-Aufruf externalplayer und Erscheinen des Kodi-Menüs. Es sollte reichen, in der softoggle ganz auf DETA/ATTA zu verzichten, wenn man das externplayer-Plugin verwendet. Ich werde da mal ein wenig weiterbasteln und auch versuchen einen Patch für softhdodroid erstellen, um die angesprochenen Probleme zu fixen.