[softhddevice-drm]

    So wieder ein Stückchen weiter, es war tatsächlich ein Rechteproblem. Nachdem der user vdr der Gruppe render hinzugefügt wurde möchte der VDR fast starten. Ich hab irgendwie das gefühl das rells softhddevice-drm sich mit dvbapi beißt. Hier mal ein Syslog ausschnitt.

    Dateien

    syslog2.txt 18,27 kB – 102 Downloads

    Vielleicht kannst du einfach mal ohne skinelchi und dvbapi starten?

    Ich sehe nur SATIP-ERRORs...

    VDR Version hast du auch nicht die neueste?

    Bis zu

    Code
    Feb  9 17:43:16 PineH64 vdr: [1218] [softhddev]cOglOsd osdLeft 154 osdTop 756 screenWidth 1920 screenHeight 1080

    siehts OSD-mäßig gut aus, aber

    Code
    Feb  9 17:43:17 PineH64 vdr[1218]: SetupFB: cannot create modifiers framebuffer (22): Invalid argument

    schaut nicht richtig aus. Ich weiß aber nicht, ob das an GL osd liegt, das hatte ich gestern auch ab und zu mit und ohne gl.

    Ich habe https://github.com/rellla/vdr-…m/tree/drm-atomic-v2-gles ein paar commits hinzugefügt, die per ssh gut zu laufen scheinen. Muss es mir aber am TV noch ansehen.

    Ich teste mal. An skinelchi lag es nicht das hab gerade eben deaktiviert, selbes Verhalten.

    Also an dvbapi lag es auch nicht. Hier mal das nächste syslog. Wenn ich mal mit debug compilieren soll musst es halt sagen ;)

    Dateien

    syslog3.txt 53,95 kB – 82 Downloads

    Einmal editiert, zuletzt von JoeBar ()

    Ja, bitte GL und DRM debugs aktivieren und die letzte Version hernehmen, ich hatte einen Tippfehler beim Logging des SetupFB Fehlers... Ich schaue es mir später mal an.

    Du kannst auch schauen, ob meine Version funktioniert, wenn du ohne GLES=1 baust. Dann weiß ich, dass der GL code der Übeltäter ist. Ansonsten hab ich vorher was vermurkst... Danke ;)

    Mit GLES=0 funktioniert das Plugin ;) Hier das nächste Log mit der aktuellen Verion aus dem Git.

    Dateien

    syslog4.txt 21,16 kB – 102 Downloads

    Danke, da funktioniert was mit dem drm FB fürs GL OSD nicht. Wenn du nichts dagegen hast, schick ich dir später was mit mehr printfs zum testen.

    Wie läuft es ohne GLES? Merkst du einen Unterschied zu zilles Original?

    Hab ich nur kurz getestet ohne GLES, und da hab ich keine Unterschiede festgestellt.

    Klar schick ich teste ;)

    JoeBar Habe die Funktion etwas umgeschrieben und logs hinzugefügt. Vielleicht kannst du es nochmal probieren und die Logs posten.

    Bei mir läufts auf H3...

    SkinElchiHD zeigt auch was an, allerdings sind da noch ein paar Dinge verschoben, mal sehen, woran das liegt.

    Gute Nachrichten, es läuft. Ich muss jetzt mal ein paar Skins noch testen. Aber mit lcars merke ich groß keinen unterschied in der Preformance bis jetzt.

    Gut. Kannst du trotzdem die Logs posten? Mich würde interessieren, was der Unterschied zu panfrost ist.

    Wenn mehrere Pixmaps gerendert werden, stimmt die Y-Ausrichtung noch nicht. Das versuche ich gerade zu korrigieren. Das macht sich z.B. bei SkinElchi bemerkbar. Hatte das vor Jahren schon mal im alten Code gefixt.


    EDIT: Habs gefunden. Ich räum jetzt dann mal auf und stells später online.

    Ich hab Dir einfach mal das Log angehängt was er bisher produziert hat. Da war das normal Skin elchi auch mit dabei. Muss mal schauen ob ich den skindesigner installiert bekomm. Dann teste ich den mal.

    Dateien

    syslog5.txt 203,46 kB – 100 Downloads

    Skindesigner metrixhd läuft aber seeeehr langsam und alles steht kopf :)

    So, nächster Versuch. Mit der neuesten Version läuft es hier mit SkinElchiHD eigentlich schon ganz ordentlich.

    Werde dann mal die anderen Skins testen und schauen, was man an der Performance noch machen kann.

    Ist SkinElchiHD auch bei skindesigner mit dabei oder ein extra Plugin?

    So gleicht mal getestet, es fühlt sich unter metrixHD schon etwas performanter an, die Menüs sind an der richtigen Position :thumbup:, das wird ;)

    Ich werd mir jetzt mal skinelchiHD anschauen.

    Zitat von JoeBar

    So gleicht mal getestet, es fühlt sich unter metrixHD schon etwas performanter an, die Menüs sind an der richtigen Position :thumbup:, das wird ;)

    Ich werd mir jetzt mal skinelchiHD anschauen.

    Wär interessant, wie es im Vergleich zu ohne GLES ist...

    zillerbaer Ich hab gestern mal etwas laufen lassen und nach einiger Zeit kommen ca. 30 Meldungen mit ret = -22

    Code
    Feb 10 23:17:10 orangepiplus rc.local[207]: /usr/local/bin/vdr.sh: Zeile 8:   302 Speicherzugriffsfehler  vdr -u root --vfat -c /etc/vdr -E /vide
Feb 10 23:17:09 orangepiplus rc.local[207]: FilterHandlerThread: ret -22 Das Argument ist ungültig
Feb 10 23:17:09 orangepiplus vdr[302]: [302] [softhddev]SetPlayMode: 0
Feb 10 23:17:09 orangepiplus vdr[302]: [302] switching to channel 31 S19.2E-1-1079-28014 (zdf_neo)
Feb 10 23:16:51 orangepiplus rc.local[207]: FilterHandlerThread: width 0 height0
Feb 10 23:16:51 orangepiplus rc.local[207]: FilterHandlerThread: ret -22 Das Argument ist ungültig

    dann kommt der segfault.

    Ich weiß nicht, ob das mit dem OSD oder mit dem Deinterlacer zusammenhängt, werde mal mit gdb einen BT machen. Aber vielleicht kannst du mir sagen, ob der Fehler kritisch ist?

    Ein segfault ist bei mir immer kritisch! Die Fehlermeldungen besagen das av_buffersink_get_frame schief geht. Ein Aufrufargument stimmt nicht. Wenn Du sagst das es erst läuft sollte buffersink_ctx in Ordnung sein. Da bleibt nur av_frame_alloc. Das hab ich leider nicht abgefangen. Das kann ich noch machen. Ich vermute das Dir der Speicher ausgeht und das AVFrame nicht angelegt werden kann. Kontrollier das mal mit htop!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden